Redis集群脑裂本质是多子集群各选主节点并发写导致数据不一致，需通过quorum多数派、min-replicas保护、哨兵混合部署及故障后人工修复三层应对。
Redis 集群在网络分区时出现脑裂，本质是多个子集群各自选出主节点、同时对外提供写服务，造成数据不一致甚至丢失。关键不在“能不能发现”，而在于“能不能阻止错误的主节点被选出来”和“能不能让旧主在恢复后不破坏新主的数据”。处理思路要兼顾预防、限制、兜底三层。
合理设置哨兵 quorum 和 down-after-milliseconds
quorum 决定多少个哨兵达成一致才能触发故障转移。如果部署了 3 个哨兵，但配置 quorum = 1，一旦任意一个哨兵与主节点失联（哪怕只是瞬时抖动或单边网络延迟），就可能发起选举——这是脑裂最常见的诱因。
- 生产环境建议：quorum ≥ ⌊sentinel总数/2⌋ + 1（即多数派原则），例如 3 个哨兵设为 2，5 个哨兵设为 3
- down-after-milliseconds 不宜过短，避免将临时卡顿误判为宕机；推荐设为 3000–5000ms，并结合业务 RT 调整
- 所有哨兵节点的这两个参数必须严格一致，否则投票逻辑错乱
启用 min-replicas-to-write 和 min-replicas-max-lag
这是从主节点自身出发的强制保护机制，属于“自我约束”策略。即使哨兵没反应过来，主节点也能主动拒绝写入，降低脑裂风险。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- min-replicas-to-write N：要求至少有 N 个从节点在线且能正常复制，主节点才接受写请求。设为 1 可防止单点主节点在失联时继续服务
- min-replicas-max-lag M：要求这些从节点的复制延迟不能超过 M 毫秒（单位：毫秒）。设为 10000 表示允许最多 10 秒延迟，太小易误拒，太大失去意义
- 两项需配合使用，配置后主节点会在 INFO replication 中显示 master_repl_offset 和各 slave 的 slave_repl_offset 差值，供验证
避免跨机房/跨可用区单点部署哨兵
脑裂高频场景之一，就是哨兵和主节点被分在同一网络分区，而从节点和另一批哨兵在另一分区——这直接导致两套“多数派”并存。
- 哨兵应与主从节点混合部署，至少保证每个可用区都有哨兵+主或哨兵+从，打破“哨兵全在一侧”的拓扑
- 不要把全部哨兵和主节点都放在同一台机器或同一个交换机下；物理隔离越强，分区时越容易形成不对称判断
- 若必须跨机房部署，建议使用奇数个机房（如 3 个），并确保任意两个机房之间网络可达性高于单链路依赖
故障后人工核验与数据修复不可跳过
自动机制只能降低概率，无法 100% 规避。一旦发生脑裂，必须立刻响应：
- 检查 redis-cli --cluster check 或 Sentinel 日志，确认哪几个节点曾短暂成为 master
- 比对各主节点的 AOF 文件末尾写入时间戳、lastsave 时间、以及 key 的过期时间分布，定位冲突写入窗口
- 优先以新主（由哨兵提升）的数据为准，将旧主降级后清空数据，再手工同步或通过业务层补偿（如基于 binlog 回溯）
- 记录本次分区持续时间、影响 key 范围、写入量，用于后续调优 down-after-milliseconds 和 min-replicas 参数
