关于Redis

Posted 2021-05-25 爪哇岛上

缓存穿透

---

缓存穿透是指用户查询一个key，redis中没有此key的缓存数据，于是向持久层查询。请求量大的时候对数据库造成很大压力，出现缓存穿透。

解决方案：

• 布隆过滤器

  将所有可能查询的key以hash形式存储在过滤器中，用户查询先经过布隆过滤器，不在布隆过滤器中即不往下查询。

  
  

• 缓存空对象

  请求查询缓存和db为空后，将空对象缓存起来，同时设置过期时间，下次查询的时候直接从缓存中取出，保护db。但是这个会占用存储空间，且缓存层和db层存储的数据可能会有一段时间窗口的不一致。

  public String get(key){
      if(null == cache.get(key)){
          String value = db.get(key);
          cache.set(key,value);
          if(null == value){
              cache.expire(key,60*5);
          }
          return value;
      }else return cache.get(key);
  }
  

缓存击穿

---

缓存击穿是指redis中存在某个key的数据，但是某个时刻并发请求时，缓存突然失效，大面积的请求到了db。造成db压力。

缓存雪崩

---

缓存雪崩是指某一时间缓存大面积失效，请求落到db层。

解决方案：

- redis集群：搭建redis集群，保证缓存高可用，防止一台redis挂掉，请求造成雪崩。
- 设置不同的过期时间：给key设置不同的过期时间，以防止在同一时间缓存大面积失效。常见的可以在设置过期时间时加一个随机因子，分散缓存的过期时间。
- 二级缓存：设置两级缓存，A1和A2，A1过期时间短，A2过期时间长，请求先访问A1，A1失效时再访问A2，并异步更新A1缓存。

布隆过滤器

---

布隆过滤器是一种高效插入查询的概率型数据结构，它是一个bit数组，如图：

数组中每项初始化为0，当映射一个值时使用多个不同的哈希函数生成多个哈希值，修改数组中对应位置为1，查询一个值时如果返回的都为1，则这个值可能存在，有一个0则这个值肯定不存在。（可能存在是因为存储的值越来越多，很多位置变成了1，查询一个值时，即使没有存储过它，但是它经哈希函数映射的位置可能都是1，造成存在的假象。）

如何选择哈希函数的个数和布隆过滤器的长度？

img

长度短的布隆过滤器和使用个数多的哈希函数的过滤器很快bit位都会变为1，误报率很高。

img

k 为哈希函数个数，m 为布隆过滤器长度，n 为插入的元素个数，p 为误报率。

引用：https://zhuanlan.zhihu.com/p/43263751

使用场景：

- 网页爬虫对URL去重
- 垃圾邮件过滤
- 解决redis缓存穿透
- 秒杀系统查看用户是否重复购买

Redis为什么这么快？

---

• 完全基于内存，绝大部分请求是内存操作，非常快速。
• 采用单线程，避免了不必要的上下文切换和竞争条件，不存在多进程或多线程导致的切换而消耗CPU，不用考虑各种锁的问题。
• 使用多路IO复用模型，非阻塞IO。

Redis 集群

---

哨兵模式下，主节点是由哨兵去选举的，但是在哨兵选举切换主从的过程中，整个redis服务是不可用的，并且哨兵模式下只有一个主节点，无法扩展，主节点压力较大，无法提供高并发服务，同时主节点的内存也不能太大，太大会影响数据备份和恢复时间以及主从同步效率，所以redis推出了redis cluster模式。

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需 要sentinel哨兵∙也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中 心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的 性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。

redis集群将redis内存划分成16384个槽位，每个节点负责其中的一部分槽位，当redis客户端连接集群时，会在本地缓存一份节点槽位信息，当查询时先在本地缓存中查到对应的节点，再去对应的节点查询数据。

槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模 来得到具体槽位。HASH_SLOT = CRC16(key) mod 16384

跳转重定位

redis集群节点间的通信机制

维护集群的元数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip

• 优点在于元数据的更新和读取，时效性非常好，一旦元数据出现变更立即就会更新到集中式的存储中，其他节 点读取的时候立即就可以立即感知到；不足在于所有的元数据的更新压力全部集中在一个地方，可能导致元数 据的存储压力。很多中间件都会借助zookeeper集中式存储元数据。

• gossip协议包含多种消息，包括ping，pong，meet，fail等等。

  meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通 信；

  ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群元数据，互相通过 ping交换元数据(类似自己感知到的集群节点增加和移除，hash slot信息等)；

  pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新；

  fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

gossip协议的优点在于元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于元数据更新有延时可能导致集群的一些操作会有一些滞后。

gossip通信的10000端口 每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几 点接收到ping消息之后返回pong消息。

网络抖动

真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见 的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。为解决这种问题，Redis Cluster 提供了一种选项cluster­node­timeout，表示当某个节点持续 timeout 的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频 繁切换 (数据的重新复制)。

redis集群选举机制

当slave发现自己的master变为FAIL状态时，便尝试发起选举，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

1.slave发现自己的master变为FAIL

2.将自己记录的集群currentEpoch（选举轮次标记）加1，并广播信息给集群中其他节点

3.其他节点收到该信息，只有master响应，判断请求者的合法性，并发送结果

4.尝试选举的slave收集master返回的结果，收到超过半数master的统一后变成新Master

5.广播Pong消息通知其他集群节点。

如果这次选举不成功，比如三个小的主从A,B,C组成的集群，A的master挂了，A的两个小弟发起选举，结果B的master投给A的小弟A1，C的master投给了A的小弟A2，这样就会发起第二次选举，选举轮次标记+1继续上面的流程。事实上从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票。同时下面公式里面的随机数，也可以有效避免slave同时发起选举，导致的平票情况。

*延迟计算公式：*DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）。

分片的集群模式可以部分提供服务，当一个小主从挂了，落在这个小主从的key查不到数据，但是其他的小主从仍然可以使用。

集群脑裂

redis集群脑裂是由于网络原因，主从节点处于不同的网络分区，salve无法感知master节点的存在而重新选举新的master节点，  客户端可能还在给旧的master节点写入数据，新的master节点没有这部分数据，造成数据的大量丢失。

解决办法：

min-slaves-to-write 1 # 连接到master的最少slave数量

min-slaves-max-lag 10 # slave连接到master的最大延迟时间

如果连接到master的slave数量小于第一个参数且ping的延迟时间不大于第二个参数，那么master就会拒绝写请求。

Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中 一个挂了，是达不到选举新master的条件的。奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的 集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举 新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

Redis管道技术（Pipeline）

---

客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低多条命令执行的网络传输开销，管道执行多条命令的网络开销实际上只相当于一 次命令执行的网络开销。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓 存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。pipeline中发送的每个command都会被server立即执行，如果执行失败，将会在此后的响应中得到信 息；也就是pipeline并不是表达“所有command都一起成功”的语义，管道中前面命令失败，后面命令不会有影响，继续执行。

哨兵leader选举流程

---

当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进 行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的 leader，选举是先到先得。同时每个sentinel每次选举都会自增配置纪元(选举周期)，每个纪元中只会选择一 个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移 操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似。哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举master，如果master挂了，那唯一的那个哨 兵节点就是哨兵leader了，可以正常选举新master。不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。