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重连后再让集群自动恢复，比人工干预更可靠
真正棘手的从来不是“怎么选”，而是“为什么不能选”——多数选举失败背后，都是节点间通信断连或数据状态不一致，而不是算法本身有问题。
