文章目录引言脑裂的发生过程从一次真实故障说起脑裂导致数据丢失的机制假故障的常见原因应对脑裂的配置方案为什么这个方案有效参数设置建议方案的局限性本质原因与思考总结引言在Redis主从集群的运维过程中有一类问题特别隐蔽——客户端写入的数据莫名其妙地丢失了。排查主从复制进度发现offset完全一致检查实例状态一切看似正常。这种幽灵般的数据丢失往往指向一个令人头疼的问题脑裂Split-Brain。脑裂的本质是主从集群中同时出现了两个主节点它们都能接收写请求。当哨兵完成切换后原主库被降级为从库并执行全量同步切换期间写入原主库的数据就会被彻底清除。脑裂的发生过程从一次真实故障说起假设我们有一个1主5从3哨兵的集群某天发现客户端写入的部分数据丢失了。按照常规思路排查第一步检查主从复制进度数据丢失最常见的原因是主库故障前数据未同步到从库。我们可以对比master_repl_offset和slave_repl_offset的差值来判断。但如果发现新主库升级前的offset与原主库完全一致说明数据同步没有问题需要另寻原因。第二步排查客户端操作日志在客户端日志中发现主从切换后的一段时间内有客户端仍然在和原主库通信。这意味着集群中同时存在两个主库——脑裂已经发生。第三步定位假故障根因既然哨兵触发了切换说明主库的心跳超时了。但客户端又能和原主库通信说明主库并没有真正宕机。检查服务器监控发现原主库所在机器的CPU利用率曾短暂飙升被同机部署的数据采集程序占满导致Redis无法响应哨兵心跳。CPU恢复后原主库又开始正常服务。脑裂导致数据丢失的机制脑裂本身只是让两个主库同时存在但数据丢失发生在后续的全量同步阶段原主库假故障期间哨兵判定其客观下线开始主从切换原主库恢复后继续接收客户端写请求此时新主库可能还未完全就绪哨兵切换完成后让原主库执行SLAVEOF命令成为新主库的从库全量同步的最后阶段原主库清空本地数据加载新主库的RDB文件切换期间写入原主库的数据被彻底丢失假故障的常见原因导致主库假死的场景主要有两类资源争抢与主库部署在同一台服务器上的其他程序临时占用大量CPU、内存或网络资源导致Redis短时间内无法响应心跳。资源释放后主库恢复正常。实例阻塞主库自身遇到阻塞比如处理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/21K1时设为1min-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 15sdown-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监控实例的阻塞情况。预防永远比事后补救更重要。