Redis脑裂现象及其应对策略

什么是 Redis 脑裂现象？

Redis 脑裂现象是指在主从集群中，由于某些原因导致同时存在两个或多个主节点，每个主节点都能接收写请求，从而引发数据不一致的问题。这种现象类似于一个人有多个大脑，每个大脑都能做出决策，但身体却不知道该听从哪一个，最终导致混乱。

具体来说，当主节点暂时“失联”但并未真正故障时，哨兵会自动触发主从切换机制，选举出新的主节点。然而，当原主节点恢复后，它仍会继续处理请求，这时集群中就会同时存在两个主节点，这就是脑裂现象。

脑裂的影响

脑裂现象最直接的影响是客户端不知道应该向哪个主节点写入数据，这会导致不同客户端将数据写入不同的主节点，从而引起数据不一致。在极端情况下，脑裂还会导致数据丢失。例如，当哨兵使原主节点与新主节点进行全量同步时，原主节点在切换期间保存的数据可能会被覆盖。

具体的数据丢失过程如下：

• 从节点向主节点发送数据同步命令；
• 主节点接收到同步命令后，生成 RDB 快照文件，并记录后续的写操作；
• 主节点将 RDB 快照文件发送给从节点，从节点清空旧数据并加载新数据；
• 主节点发送后续的写操作命令，从节点接收并执行，完成数据同步；
• 此后，主节点每次执行写操作都会同步到从节点，以保持数据一致性。

在这个过程中，原主节点需要清空本地数据并加载新主节点发送的 RDB 文件，因此在主从切换期间保存的新数据会被丢失。

数据丢失一定是脑裂引起的吗？

数据丢失并不一定是由脑裂引起的。最常见的原因是主节点的数据尚未完全同步到从节点，而主节点在此时发生故障。当从节点升级为主节点后，未同步的数据就会丢失。

判断数据丢失是否由脑裂引起的方法是检查主从节点的复制进度差值，即比较 master_repl_offset 和 slave_repl_offset。如果从节点的 slave_repl_offset 小于原主节点的 master_repl_offset，则可以认为数据丢失是由数据同步未完成导致的。

此外，还可以通过查看客户端的操作日志来判断是否发生了脑裂。如果在主从切换后的一段时间内，有客户端仍在与原主节点通信，而没有与新主节点进行交互，这表明集群中同时存在两个主节点，从而确认发生了脑裂。

如何解决脑裂问题？

Redis 提供了两个关键配置项来解决脑裂问题，分别是 min-slaves-to-write 和 min-slaves-max-lag。

min-slaves-to-write 表示主节点必须至少有 N 个健康的从节点存活才能执行写操作。这一配置虽然不能保证所有从节点都能接收到主节点的写操作，但可以避免在没有足够健康从节点的情况下，主节点无法正常写入，从而减少数据丢失的风险。

min-slaves-max-lag 表示从节点与主节点进行数据复制时的 ACK 消息延迟的最大时间。如果从节点的 ACK 消息延迟超过设定的时间，主节点将拒绝写操作。

这两个配置项结合使用，要求主节点连接的从节点中至少有 N 个从节点，且这些从节点与主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒。这样，即使原主节点只是暂时失联，它也无法响应哨兵的心跳测试，也无法与从节点进行同步，从而无法进行 ACK 确认。在这种情况下，min-slaves-to-write 和 min-slaves-max-lag 的组合要求无法得到满足，原主节点将被限制接收客户端请求，客户端也无法在原主节点中写入新数据，从而避免脑裂现象的发生。