redis cluster故障转移由主节点失联且多数主节点投票确认触发；从节点需满足复制偏移量达标、获多数主节点投票才能当选新主。
Redis Cluster 故障转移靠什么触发
不是所有节点宕机都会立刻触发故障转移，关键看是不是主节点挂了，以及有没有足够多的主节点在线投票。Redis Cluster 用的是类 Raft 的多数派投票机制，但不依赖日志复制——它只对“某个主节点是否失联”这件事发起投票。
-
cluster-node-timeout是心跳超时阈值（默认 15000ms），从其他主节点视角，如果连续cluster-node-timeout没收到目标主节点的 PING/PONG 响应，就把它标记为PFAIL（可能失效） - 只有当**超过半数的主节点**（N/2 + 1，N 是当前在线主节点总数）都标记该主节点为
PFAIL，才会升级为FAIL，并启动故障转移流程 - 注意：这里统计的是「主节点数量」，不是总节点数。比如 6 节点集群（3 主 3 从），只要 2 个主节点在线，就只需要其中 2 个都同意就能判
FAIL
从节点如何被选为新主节点
一旦原主节点被判定为 FAIL，它的从节点会尝试发起选举。能不能当选，不看谁先喊，而看谁能拿到大多数主节点的投票，且自身复制偏移量（replication offset）最接近原主节点。
- 从节点在发起选举前，会先检查自己的
slave-repl-offset是否 >= 当前已知的最大偏移量（通过向其他节点发送CLUSTER NODES或INFO replication获取）；落后太多直接放弃 - 每个主节点在同一轮选举中只投一票，投给第一个收到合法
FAILOVER_AUTH_REQUEST的从节点 - 选举超时由
cluster-node-timeout控制，一般 1–2 秒内完成；失败则重试，最多尝试cluster-slave-validity-factor × cluster-node-timeout毫秒
为什么有时候故障转移卡住或失败
最常见的不是网络分区，而是配置或拓扑导致的“投票无法达成多数”。尤其是小规模集群或手动干预后状态混乱时。
- 集群中只剩 1 个主节点在线 → 无法凑够 N/2 + 1 票，永远卡在
PFAIL，不会升级FAIL - 从节点设置了
cluster-require-full-coverage no，但部分哈希槽（slot）没有主节点负责，整个集群会拒绝写入，但不影响故障转移本身 - 从节点与原主节点断连太久，
slave-repl-offset落后过多，且cluster-slave-validity-factor设得太小（默认 10），导致它连参选资格都没有 - 人为执行过
CLUSTER FAILOVER FORCE或CLUSTER FAILOVER TAKEOVER，可能让多个从节点同时发起选举，造成短暂脑裂（虽然后续能收敛）
怎么验证当前集群是否健康、能否正常故障转移
别等真挂了才查，日常用几条命令快速摸清底数。重点不是“有没有从节点”，而是“它们能不能被选上”。
- 运行
CLUSTER NODES，确认每组主从关系里，从节点状态是slave且connected，并且master字段指向正确的主节点 ID - 对每个从节点执行
INFO replication，检查master_link_status:up和slave_repl_offset是否持续增长 - 用
redis-cli --cluster check <any-node></any-node>检查槽分配和主从映射一致性；它会明确报出 “Not all 16384 slots are covered” 或 “Some slaves are not serving the same master” 这类硬伤 - 测试性模拟：停掉一个主节点，观察 30 秒内是否出现
fail?<node-id></node-id>变成fail<node-id></node-id>，再看对应从节点的 role 是否从slave变成master
真正容易被忽略的，是 cluster-node-timeout 和 cluster-slave-validity-factor 这两个参数的联动效果：前者决定“多久算失联”，后者决定“落后多少就不能参选”。调得太激进，可能误切；太保守，又拖慢恢复。线上环境建议先在测试集群里用 DEBUG SLEEP 模拟延迟，再观察投票行为。
