Redis - 主从集群脑裂：数据丢失的隐藏杀手

引言

在Redis主从集群的运维过程中，有一类问题特别隐蔽——客户端写入的数据莫名其妙地丢失了。排查主从复制进度，发现offset完全一致；检查实例状态，一切看似正常。这种"幽灵般"的数据丢失，往往指向一个令人头疼的问题：脑裂（Split-Brain）。

脑裂的本质是主从集群中同时出现了两个主节点，它们都能接收写请求。当哨兵完成切换后，原主库被降级为从库并执行全量同步，切换期间写入原主库的数据就会被彻底清除。

脑裂的发生过程

从一次真实故障说起

假设我们有一个1主5从3哨兵的集群，某天发现客户端写入的部分数据丢失了。按照常规思路排查：

第一步：检查主从复制进度

数据丢失最常见的原因是主库故障前数据未同步到从库。我们可以对比master_repl_offset和slave_repl_offset的差值来判断。但如果发现新主库升级前的offset与原主库完全一致，说明数据同步没有问题，需要另寻原因。

第二步：排查客户端操作日志

在客户端日志中发现，主从切换后的一段时间内，有客户端仍然在和原主库通信。这意味着集群中同时存在两个主库——脑裂已经发生。

第三步：定位假故障根因

既然哨兵触发了切换，说明主库的心跳超时了。但客户端又能和原主库通信，说明主库并没有真正宕机。检查服务器监控发现，原主库所在机器的CPU利用率曾短暂飙升（被同机部署的数据采集程序占满），导致Redis无法响应哨兵心跳。CPU恢复后，原主库又开始正常服务。

脑裂导致数据丢失的机制

脑裂本身只是让两个主库同时存在，但数据丢失发生在后续的全量同步阶段：

1. 原主库假故障期间，哨兵判定其客观下线，开始主从切换
2. 原主库恢复后继续接收客户端写请求（此时新主库可能还未完全就绪）
3. 哨兵切换完成后，让原主库执行SLAVEOF命令，成为新主库的从库
4. 全量同步的最后阶段，原主库清空本地数据，加载新主库的RDB文件
5. 切换期间写入原主库的数据被彻底丢失

假故障的常见原因

导致主库"假死"的场景主要有两类：

1. 资源争抢：与主库部署在同一台服务器上的其他程序临时占用大量CPU、内存或网络资源，导致Redis短时间内无法响应心跳。资源释放后主库恢复正常。

2. 实例阻塞：主库自身遇到阻塞，比如处理bigkey、发生内存swap、执行耗时的AOF重写等。阻塞解除后恢复正常请求处理。

这两种情况的共同特点是：主库并没有真正挂掉，只是暂时"失联"。

应对脑裂的配置方案

Redis提供了两个配置项来限制主库在"失联"状态下接收请求：

min-slaves-to-write1min-slaves-max-lag12

这两个参数的含义是：

• min-slaves-to-write：主库能进行数据同步的最少从库数量
• min-slaves-max-lag：从库给主库发送ACK消息的最大延迟（秒）

组合使用的逻辑是：主库连接的从库中，至少有N个从库的ACK延迟不超过T秒，否则主库拒绝接收客户端写请求。

为什么这个方案有效

当原主库发生假故障时：

• 无法响应哨兵心跳
• 同样无法和从库进行正常的数据同步
• 从库的ACK消息自然会超时
• min-slaves-to-write和min-slaves-max-lag的条件无法满足
• 原主库自动拒绝客户端写请求

这样即使原主库从假故障中恢复，也不会接收新的写入，避免了数据丢失。

参数设置建议

假设从库有K个：

# min-slaves-to-write 设置为 K/2+1（K=1时设为1）min-slaves-to-write3# 假设5个从库# min-slaves-max-lag 设置为10~20秒min-slaves-max-lag12# 哨兵的 down-after-milliseconds 应小于 min-slaves-max-lagsentinel down-after-milliseconds mymaster10000

关键原则：min-slaves-max-lag要大于down-after-milliseconds，这样在哨兵判定主库下线时，主库已经因为ACK超时而拒绝写入了。

方案的局限性

需要注意的是，这个方案并不能100%防止数据丢失。考虑以下场景：

• min-slaves-max-lag= 15s
• down-after-milliseconds= 10s
• 哨兵切换耗时 = 5s
• 主库卡住时间 = 12s

主库卡住12s后恢复，此时哨兵已判定其下线但切换尚未完成（还需3s）。由于卡住时间12s <min-slaves-max-lag15s，原主库恢复后仍可接收写请求。这3秒窗口期内的写入，在切换完成后仍会丢失。

本质原因与思考

脑裂问题的根本原因在于：Redis主从集群内部没有通过共识算法来维护数据的强一致性。不同于ZooKeeper每次写请求必须大多数节点确认才算成功，Redis的主从复制是异步的，这是性能与一致性之间的权衡。

min-slaves-to-write和min-slaves-max-lag只能尽量减少数据丢失，无法完全杜绝。在对数据一致性要求极高的场景下，需要在应用层做额外的保障措施。

总结

脑裂是Redis主从集群中一个需要重点关注的问题。通过合理配置min-slaves-to-write和min-slaves-max-lag，可以在大多数场景下有效预防脑裂导致的数据丢失。同时，在运维层面也要注意：避免在Redis主库所在服务器上部署资源密集型程序，及时处理bigkey，监控实例的阻塞情况。预防永远比事后补救更重要。