为什么Redis Cluster至少需要3个主节点才能保证高可用-Redis-PHP中文网

redis cluster 不能用2个主节点实现高可用，因为故障转移依赖多数派投票（quorum），2个主节点无法满足“需≥⌊n/2⌋+1票”（n=2时需2票）的强制要求；一旦一个主节点失联，剩余主节点仅1票，无法达成共识，集群进入clusterdown状态并拒绝写入。

为什么redis cluster至少需要3个主节点才能保证高可用

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 返回异常或部分槽未覆盖