集群脑裂及防止

什么是集群脑裂

Redis Cluster 脑裂（Split Brain）是指集群由于网络分区导致节点之间的通信中断，不同分区内的节点各自做出独立的决策，导致集群状态不一致的现象。

在 Redis Cluster 中，最典型的脑裂场景是：主节点 A 和它的从节点 B 之间的网络中断，但由于某种原因（如哨兵或集群本身）B 被提升为新的主节点。当网络恢复后，集群中出现两个主节点都认为自己是”合法主节点”的局面。

脑裂的具体场景

场景一：主节点网络隔离

[客户端] ←→ [主节点 A] ─── 网络断开 ─── [从节点 A1, A2]
                        ↕
               [其他主节点 B, C, D...]

当主节点 A 和其他节点之间的网络中断（但与客户端仍正常通信）时：
1. 其他节点通过 Gossip 发现 A 不可达，将 A 标记为 PFAIL → FAIL
2. 集群将从节点 A1 提升为新的主节点
3. 此时集群中存在两个主节点：A（服务客户端）和 A1（被集群认可）
4. 客户端继续向 A 写入数据——这些数据在 A 恢复通信后会丢失

场景二：哨兵架构中的脑裂

在主从+哨兵架构中，如果主节点和哨兵之间网络中断：
1. 哨兵选举新的主节点
2. 旧主节点恢复通信后，被降级为从节点
3. 降级过程中旧主节点上未同步的数据被丢弃

集群脑裂的危害

脑裂最直接的后果是数据丢失。当主节点被隔离期间接收到的写入数据，在恢复后会被丢弃，因为集群认为这些数据来自一个”过期”的主节点。

时间线：
T0: 主节点 A 正常服务，A 写入 key1
T1: A 与集群网络断开，但客户端仍可写入 A
T2: A1 被提升为新主节点，客户端写入 A1
T3: A 恢复网络，被降级为 A1 的从节点
T4: A 的清空操作 → ***写入 A 的 key2、key3 全部丢失 ***

如何防止脑裂

方法一：cluster-node-timeout

在 Redis Cluster 中，合理的 cluster-node-timeout 设置可以在一定程度上减少脑裂窗口：

cluster-node-timeout 15000  # 15 秒

• 如果主节点在 cluster-node-timeout 时间内无法与半数以上主节点通信，它会停止接受写入
• 这样可以减少脑裂期间写入的数据量

方法二：min-replicas-to-write 和 min-replicas-max-lag

这是最有效的防止数据丢失的配置组合：

min-replicas-to-write 1      # 至少 1 个从节点在线
min-replicas-max-lag 10      # 从节点延迟不超过 10 秒

含义：主节点写入前，必须至少有 1 个从节点与其保持连接且数据延迟不超过 10 秒。如果从节点都断开了，主节点停止写入。

这样当网络分区发生时：
1. 主节点无法与从节点同步 → 写入被拒绝
2. 脑裂期间不会有新数据写入旧主节点
3. 即使发生主从切换，也不会因为脑裂丢失数据

方法三：哨兵架构的 quorum 配合

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel failover-timeout mymaster 180000

合理的 quorum 和超时时间可以降低误判概率，减少不必要的脑裂触发。

方法四：合理的网络规划

• 使用可靠的网络基础设施
• 避免跨机房部署 Redis Cluster（时延和分区风险更高）
• 如果需要跨机房，考虑专门的异地多活方案

面试重点

脑裂导致的数据丢失是不可逆的，防胜于治。最有效的防护手段是：

1. min-replicas-to-write：要求至少 N 个从节点在线
2. min-replicas-max-lag：限制从节点最大延迟

这两个参数确保主节点在失去所有从节点时停止写入，从根本上杜绝了脑裂期间的数据写入。

总结

脑裂是 Redis 分布式架构中不可完全避免的问题（网络不可靠是分布式系统的底层假设），但通过合理的参数配置可以将其影响降到最低。掌握 min-replicas-to-write 和 min-replicas-max-lag 的组合使用，是面试中展示对 Redis 脑裂问题理解深度的关键。