Redis Cluster 不能用2个主节点实现高可用，因为故障转移依赖多数派投票（quorum），2个主节点无法满足“需≥⌊N/2⌋+1票”（N=2时需2票）的强制要求；一旦一个主节点失联，剩余主节点仅1票，无法达成共识，集群进入CLUSTERDOWN状态并拒绝写入。
Redis Cluster 为什么不能用 2 个主节点做高可用
因为 cluster-node-timeout 和故障判定依赖多数派（quorum）投票，2 个主节点无法形成多数派。当其中一个主节点失联时，剩下那个主节点只能投自己 1 票，而 cluster-require-full-coverage 默认为 yes，且故障转移要求“超过半数主节点同意”，即至少需要 ⌊N/2⌋+1 票 —— 对 N=2 来说，这个值是 2，但只剩 1 个活着的主节点，无法达成共识。
结果就是：集群卡在 fail 状态，拒绝写入（CLUSTERDOWN Hash slot not served），整个集群不可用。
- 1 个主节点：挂了就全挂，无冗余
- 2 个主节点：任意一个失联 → 剩余节点无法触发故障转移 → 集群写失败
- 3 个主节点：允许 1 个失联，剩余 2 个仍可构成多数（2 > 3/2），继续提供服务
3 主节点如何支撑故障转移流程
Redis Cluster 的故障转移不是靠哨兵协调，而是由存活的主节点通过 Gossip 协议交换状态后，自主发起投票。关键动作发生在从节点晋升阶段：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 从节点发现其主节点 PING 超时（超
cluster-node-timeout，默认 15000ms）后，向其他节点广播FAILOVER_AUTH_REQUEST - 每个收到请求的主节点，若确认原主节点确已失联，会返回
FAILOVER_AUTH_ACK - 该从节点需收到 ≥ ⌊N/2⌋+1 个主节点的 ACK 才能晋升 —— N=3 时，需 ≥ 2 个 ACK
- 晋升成功后，它更新自己的配置纪元（
configEpoch），并广播新配置
如果只有 2 个主节点，一旦其中一个宕机，剩下的主节点无法凑够 2 票（它自己 + 另一个已失联），投票直接失败。
少于 3 主节点的「伪高可用」陷阱
有人尝试用 2 主 2 从（共 4 节点）部署，以为“有从节点就能切”，但这是错觉。因为：
- 从节点本身不参与投票，只有主节点有投票权
-
redis-cli --cluster create ... --cluster-replicas 1在 2 主时会报错：Invalid argument: number of masters must be at least 3 - 即使强行改配置绕过校验（如 patch 源码），Gossip 协议层的 quorum 判定逻辑仍硬编码为 N≥3，运行时必然卡死
- 哈希槽分配也受限：16384 个槽必须被非空划分到 ≥3 个主节点，否则
CLUSTER SLOTS返回异常或部分槽未覆盖
为什么不是 4 或 5 个主节点起步
3 是理论下限，不是推荐上限。生产环境常选 5 或 7 主，但起步必须 ≥3：
- 3 主已满足最小 quorum（2 票）、最小分片粒度（16384/3 ≈ 5461 槽/主）、最小故障容忍（1 节点故障不影响服务）
- 加到 4 主反而降低容错能力：4 主允许故障数仍是 1（因为 ⌊4/2⌋ = 2，需 ≥3 票才能转移；挂 2 个就卡住），但资源开销翻倍
- 5 主可容忍 2 节点故障（需 ≥3 票），但运维复杂度、Gossip 消息量、配置同步延迟都明显上升
- 真正容易被忽略的是：哪怕只跑 3 主，也必须配齐对应从节点（
--cluster-replicas 1），否则主挂了没备胎，还是单点
