Redis|青训营笔记缓存缓存雪崩当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系

这是我参与「第五届青训营」伴学笔记创作活动的第 8 天

缓存

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。

解决方法：在设置过期时间时采用随机数，可以防止大量数据在同一时间过期。

key对应的数据在数据源并不存在，每次针对此key的请求从缓存获取不到，请求都会到数据源，从而可能压垮数据源。比如用一个不存在的用户id获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

解决方法：采用布隆过滤，将所有可能的key值的hash存入到一个bitmap中，在请求到来时判断key是否存在于bitmap中，如果不存在就拒绝掉；采用空值返回，并且将空值储存在缓存中，可以防止查找数据库，空值的过期时间不宜过长，否则会占用内存。

key对应的数据存在，但在redis中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方法：使用互斥锁，保证只有一个线程去数据库中查询，该线程查询完后将结果保存至缓存中，其他线程重试或者降级。

Redis 的主从复制可以将主节点的数据同步给从节点,实现主从一致,这样从节点起到两个作用:

但是主从复制也有几个问题:

一旦主节点出现故障,需要手动将一个从节点升为主节点(slave no one),同时需要修改应用方的主节点地址(改为之前的从节点地址),还需要命令其他从节点去复制新的主节点,整个过程都需要人工的干预
主节点的写能力受到单机的限制
主节点的存储能力受到单机的限制其中第一个问题是高可用问题,用redis Sentinel可以解决,下面两个问题是分布式的问题,将在后续笔记中展现。

在Redis的主从复制下,一旦主节点出现了故障不可达的情况,需要人工进行干预,把从节点升级为主节点,其他从接待你复制新的主节点,还要干预应用方,这样是不能接受的,会造成一些数据的丢失。

接下来会介绍主从复制模式下,主节点出现故障是如何进行故障转移的 :

上述的这些流程如果是人工干预那么就不是高可用的,整个故障转移过程有些公司已经自动化了,但也要考虑三个问题:

以上的所有问题都可以用Redis Sentinel实现(主从复制故障转移的高可用问题)

Redis Sentinel是一个分布式架构(Redis数据节点,Sentinel节点集合,客户端分布在多个物理节点的架构),其中包含多个Redis Sentinel节点和Redis数据节点

每个Sentinel节点都会对Redis数据节点和其他Sentinel节点进行监控,当发现其他节点不可达的时候,会对节点做一个下线的标志
如果被标志的是主节点,他会和其他的Sentinel节点协商,大多数Sentinel节点认为主节点不可达的时候,会推选出一个Sentinel节点完成主从故障的功能
这一套都是自动的,完成后会通知应用方,这实现了高可用性

Redis主从复制模式和Redis Sentinel架构的区别(如图):

结构上可以知道redis Sentinel会定期对所有节点进行监控和进行故障转移

下面进行Redis Sentinel的例子进行故障转移说明(一共四步,第四步是Redis Sentinel领导者节点执行故障转移的步骤):

主节点出现故障,从节点与主节点失去连接
Redis Sentinel通过检测,检测到主节点故障
Redis Sentinel推选出一个Sentinel节点进行执行故障转移
Redis Sentinel进行故障转移
- 从节点执行slave no one
- 从节点复制新的节点
- Sentinel通知客户端
- 原来主节点复制新的主节点如图:

通过Redis Sentinel故障转移可以得知Redis Sentinel具有以下几个功能: