Redis集群选举必须过半数Master同意，因其采用类Raft共识机制，要求至少(N/2+1)个在线Master投票通过，以防网络分区导致脑裂和数据不一致。

Redis集群选举为什么必须过半数Master同意

因为Redis集群使用类Raft的分布式共识机制，不是谁先喊“我当主节点”就算数——它要求至少 (N/2 + 1) 个主节点（N 是当前在线的主节点总数）在故障转移中投出“赞成票”，否则晋升不生效。这是防止网络分区（network partition）下出现“脑裂”：比如集群被切为两组，各自选出一个主节点，导致同一份slot数据被两个主节点同时写入，彻底破坏一致性。

如何验证当前集群是否满足“过半数Master在线”

执行 redis-cli -c -a <password> cluster nodes</password>，重点看三件事：

• 统计所有状态为 master 且没有 fail 或 handshake 标记的行数 → 这是实际可用的Master数量 N
• 检查是否有主节点显示 fail? 或长期无响应 → 它们不参与投票，也不计入 N
• 确认集群整体状态不是 fail：若 redis-cli cluster info 返回 cluster_state:fail，说明已跌破法定人数，无法发起任何选举

例如，6个Master节点中2个宕机且标记为 fail，则 N = 4，法定票数为 3；若只剩2个Master在线，N = 2，法定票数为 2，但此时只要再丢1个，就彻底无法选举。

什么情况下会卡在“等票”阶段，迟迟不晋升

常见于以下真实场景：

• cluster-node-timeout 设得太小（如 3000），网络抖动被误判为节点失效，触发无效选举，但其他Master因未同步到足够信息而拒绝投票
• 从节点尚未完成全量同步（slave_repl_offset 远落后于原Master），即使它想参选，其他Master发现其数据陈旧，直接跳过该节点
• 多个从节点几乎同时发起选举请求，但彼此收到请求时还未更新本地的 currentEpoch 和 configEpoch，导致互相否决（日志里会出现 Ignoring vote request）
• 防火墙或安全组只放行了客户端端口（6379），没放开集群总线端口（16379），节点间无法交换投票消息，心跳都收不到

手动触发选举时，如何避免“票不够”失败

不要直接对从节点执行 cluster failover —— 它默认走“强制模式”，绕过投票，但仅限本节点与主节点在同一网络分区且主节点实际存活时才安全。生产环境推荐：

• 先用 redis-cli --cluster check <node></node> 确认集群健康度和各节点偏移量
• 对目标从节点执行 cluster failover TAKEOVER（需 Redis 5.0+），它会跳过投票，但要求你明确承担脑裂风险
• 更稳妥的做法是：临时调大 cluster-node-timeout（比如从5000→15000），等网络稳定、多数Master重连后再让集群自动恢复，比人工干预更可靠

真正棘手的从来不是“怎么选”，而是“为什么不能选”——多数选举失败背后，都是节点间通信断连或数据状态不一致，而不是算法本身有问题。