Redis集群脑裂本质是多主并存，源于仲裁机制失效而非配置未开启；其核心控制参数为cluster-require-full-coverage和cluster-node-timeout，而非主节点数量过半。
Redis集群脑裂的本质是“多主并存”，不是配置没开，而是仲裁机制失效
Redis Cluster 本身没有强制的“半数以上主节点存活才能服务”逻辑——它只在故障转移时要求多数派（quorum）参与投票，但日常写入完全不检查集群健康度。所谓“要求半数主节点存活才对外服务”，其实是误把 Raft 或 ZooKeeper 的模型套到了 Redis 上。真实情况是：只要一个 master 节点在线、slot 映射没被重新分配，它就照常接收写请求，哪怕其余 5 个 master 全部失联。
真正起作用的是 cluster-require-full-coverage 和 cluster-node-timeout
这两个参数才是控制集群“是否愿意降级服务”的关键开关：
-
cluster-require-full-coverage yes：默认开启。一旦有任意 slot 没有可用节点（比如某个 master 宕机且无从节点接管），整个集群拒绝所有请求（返回CLUSTERDOWN）。这是最粗暴但有效的“保一致性”策略。 -
cluster-require-full-coverage no：允许部分 slot 不可用，其余 slot 继续服务。脑裂风险陡增——分区两侧都可能各自持有部分 slot 的 master 权限，同时写入，数据必然分裂。 -
cluster-node-timeout 15000（单位毫秒）：节点间心跳超时阈值。设太小（如 3000）易因网络抖动误判下线，触发不必要的故障转移；设太大（如 60000）则恢复慢，脑裂窗口拉长。生产建议 10–15 秒，配合网络监控调优。
靠“主节点数量过半”防脑裂？Redis Cluster 不认这个逻辑
Redis Cluster 的故障转移投票基于 Gossip 协议中的节点状态共识，不是数主节点个数。它要求“大多数哈希槽负责节点（含主从）达成一致”，但这个“大多数”指的是参与通信的节点数，不是主节点数。你部署 6 主 6 从共 12 节点，网络分区成 7+5，7 节点那侧能发起选举，5 节点那侧不能——但这和“主节点是否过半”无关，只和能否凑够 (N/2)+1 个可通信节点有关。
- 常见误解：
min-slaves-to-write在 Cluster 模式下无效（该参数仅用于主从+哨兵模式） - 真正可用的防护是
cluster-slave-validity-factor：它限制从节点晋升资格。例如设为 10，且cluster-node-timeout是 15000，则从节点必须在 150 秒内与主节点有过通信，才有资格参选。避免网络短暂中断后老从节点“抢主”。 - 别指望靠节点数量硬防：3 主 3 从集群中，哪怕只剩 1 主 1 从在线，只要它们能互相通信、slot 覆盖完整，照样提供全量服务——此时若另一分区也剩 1 主 1 从，脑裂已成定局。
合理规划主从分布 ≠ 物理隔离，而是在拓扑上切断单点故障链
所谓“合理分布”，核心是让主从不共用同一故障域——不是跨机房就行，得看实际依赖路径：
- 同机架交换机 → 高风险：一台交换机宕，主从全挂
- 同供电单元 → 高风险：一次断电，整排机器失联
- 同云厂商可用区（AZ）→ 中风险：AZ 故障即整体不可用
- 跨 AZ + 独立网络平面 + 独立电源 → 低风险基线
实操建议：每个分片（master）的从节点，必须落在与主节点不同的 AZ，并确保两者之间延迟 <= cluster-node-timeout / 3（例如 timeout=15000ms，则延迟应 ≤5000ms），否则从节点大概率被判定为不可用，丧失故障转移能力。
最容易被忽略的一点：Redis Cluster 的 Gossip 流量走的是 cluster bus 端口（默认比 redis port 大 10000，如 6379 → 16379），这个端口必须和 redis 端口一样开放、低延迟、不被 ACL 或安全组截断。很多脑裂现场，根本不是业务网络问题，而是 cluster bus 端口被防火墙静默丢包，节点彼此“看不见”，直接退化成多个孤岛集群。
