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

文章目录

引言
脑裂的发生过程
- 从一次真实故障说起
- 脑裂导致数据丢失的机制
假故障的常见原因
应对脑裂的配置方案
本质原因与思考
总结

引言

在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提供了两个配置项来限制主库在"失联"状态下接收请求：

bash 复制代码

min-slaves-to-write 1
min-slaves-max-lag 12

这两个参数的含义是：

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

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

为什么这个方案有效

当原主库发生假故障时：

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

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

参数设置建议

假设从库有K个：

bash 复制代码

# min-slaves-to-write 设置为 K/2+1（K=1时设为1）
min-slaves-to-write 3  # 假设5个从库

# min-slaves-max-lag 设置为10~20秒
min-slaves-max-lag 12

# 哨兵的 down-after-milliseconds 应小于 min-slaves-max-lag
sentinel down-after-milliseconds mymaster 10000

关键原则：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-lag 15s，原主库恢复后仍可接收写请求。这3秒窗口期内的写入，在切换完成后仍会丢失。

本质原因与思考

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

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

总结

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