Redis 脑裂问题是指，在 Redis 哨兵模式或集群模式中，由于网络原因，导致主节点（Master）与哨兵（Sentinel）和从节点（Slave）的通讯中断，此时哨兵就会误以为主节点已宕机，就会在从节点中选举出一个新的主节点，此时 Redis 的集群中就出现了两个主节点的问题，就是 Redis 脑裂问题。
脑裂问题影响
Redis 脑裂问题会导致数据丢失，为什么呢？来看脑裂问题产生的过程：
图片
而最后一步，当旧的 Master 变为 Slave 之后，它的执行流程如下：
- Slave（旧 Master）会向 Master（新）申请全量数据。
- Master 会通过 bgsave 的方式生成当前 RDB 快照，并将 RDB 发送给 Slave。
- Slave 拿到 RDB 之后，先进行 flush 清空当前数据（此时第四步旧客户端给他的发送的数据就丢失了）。
- 之后再加载 RDB 数据，初始化自己当前的数据。
从以上过程中可以看出，在执行到第三步的时候，原客户端在旧 Master 写入的数据就丢失了，这就是数据丢失的问题。
如何解决脑裂问题？
脑裂问题只需要在旧 Master 恢复网络之后，切换身份为 Slave 期间，不接收客户端的数据写入即可，那怎么解决这个问题呢？
Redis 为我们提供了以下两个配置，通过以下两个配置可以尽可能的避免数据丢失的问题：
- min-slaves-to-write：与主节点通信的从节点数量必须大于等于该值主节点，否则主节点拒绝写入。
- min-slaves-max-lag：主节点与从节点通信的 ACK 消息延迟必须小于该值，否则主节点拒绝写入。
这两个配置项必须同时满足，不然主节点拒绝写入。
在假故障期间满足 min-slaves-to-write 和 min-slaves-max-lag 的要求，那么主节点就会被禁止写入，脑裂造成的数据丢失情况自然也就解决了。
