redis-脑裂问题

目录

1. 什么是Redis脑裂问题？

2. 脑裂问题的影响？

3. 如何解决脑裂问题？

---

学技术之余，不要忘记吃饭哦，送大家一个外卖红包，快来扫码领取吧！

内有更多惊喜哦【坏笑～】

1. 什么是Redis脑裂问题？

脑裂，顾名思义，大脑裂开，产生了两个脑袋，出现了混乱。其实，Redis 脑裂问题是指：在 Redis 哨兵模式或集群模式中，由于网络原因，导致主节点（Master）与哨兵（Sentinel）和从节点（Slave）的通讯中断，因此，哨兵在无法与主节点通信的情况下，误认为主节点已经挂了，进而重新选举出了一个主节点。当假死状态的主节点恢复后，此时Redis集群中有两个主节点的现象，就是脑裂。

2. 脑裂问题的影响？

首先，我们来复盘一下脑裂问题的产生过程。

1. 正常情况下，我们的redis集群应该是这样的：

2. 突然，master出了问题：

3. 哨兵重新选定主节点，同时客户端发起新的数据写入请求：

4. 重要：旧的客户端数据写入旧的主节点：

5. 过一会，旧的主节点恢复通信，重新加入集群（旧的主节点中，有旧的客户端写入的数据，同时也在写入新数据），此时集群中有两个主节点：

6. 当旧的主节点发现新的主节点后，旧的主节点变为从节点：

在最后这一步，当旧的 Master 变为 Slave 之后，它的执行流程如下：

• Slave（旧 Master）会向 Master（新）申请全量数据。
• Master 会通过 bgsave 的方式生成当前 RDB 快照，并将 RDB 发送给 Slave。
• Slave 拿到 RDB 之后，先进行 flush 清空当前数据（此时第四步旧客户端给他的发送的数据就丢失了）。
• 之后再加载 RDB 数据，初始化自己当前的数据。

从以上过程中可以看出，在执行到第3步的时候，原客户端在旧 Master 写入的数据就丢失了，这就是数据丢失的问题。

3. 如何解决脑裂问题？

思路：

其实脑裂的影响在于旧 Master 恢复网络之后，切换身份为 Slave 期间，不接收客户端的数据写入即可。

实现方式：

Redis 为我们提供了以下两个配置，通过以下两个配置可以尽可能的避免数据丢失的问题：

• min-slaves-to-write：与主节点通信的从节点数量必须大于等于该值主节点，否则主节点拒绝写入。
• min-slaves-max-lag：主节点与从节点通信的 ACK 消息延迟必须小于该值，否则主节点拒绝写入。

这两个配置项必须同时满足，不然主节点拒绝写入。

在假故障期间满足 min-slaves-to-write 和 min-slaves-max-lag 的要求，那么主节点就会被禁止写入，脑裂造成的数据丢失情况自然也就解决了。