Redis哨兵故障转移分两阶段：先由≥quorum哨兵投票选出Leader，再由Leader按健康检查、优先级、offset、run_id四层规则筛选新主；原主恢复后自动降为从节点。
Redis哨兵模式的故障转移不是随机选一个从节点顶上，而是有明确的两阶段选举机制：先选一个领头哨兵（Leader Sentinel），再由它执行新主节点（new master）的筛选。跳过这个分步逻辑，直接调 SENTINEL failover 或改配置，大概率触发脑裂或选错节点。
sentinel failover 触发后实际发生了什么
手动执行 SENTINEL failover <master-name> 或自动进入故障转移，并不等于立刻切换主从。它只是向哨兵集群广播“我要开始选主了”，后续所有动作都依赖两个独立但串行的选举：
- 第一轮：所有在线哨兵基于 Raft-like 投票选出唯一 Leader（必须获得 ≥
quorum票） - 第二轮：该 Leader 单独执行从节点打分排序，按规则逐层过滤，最终锁定一个晋升目标
- 整个过程受
sentinel failover-timeout限制（默认 180000ms），超时则本次 failover 失败，需重试
quorum 参数如何影响投票结果与脑裂风险
quorum 不是“投票总数”，而是判定主节点“客观下线”所需的最小同意哨兵数，它直接决定第一轮 Leader 选举能否成功启动：
- 若配置
sentinel monitor mymaster 127.0.0.1 6379 2，而当前只有 2 个哨兵在线 → 无法达成多数派 → 故障转移卡在“等待更多哨兵响应” - 3 个哨兵配
quorum 2是安全下限；5 个哨兵建议配quorum 3，避免网络分区时两边各得 2 票导致双主 -
quorum过小（如 3 哨兵配 1）会导致误判：单个哨兵网络抖动就触发 failover；过大（如 5 哨兵配 5）则丧失容错能力
新主节点筛选的四层规则必须按顺序执行
Leader 哨兵不会凭经验或 ping 延迟拍板，而是严格走完以下漏斗式过滤：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
第一层健康检查：排除主观下线、断连、
INFO命令失败的从节点 -
第二层优先级：读取每个从节点的
slave-priority配置（默认 100），值越小越优先；设为 0 表示禁止晋升 -
第三层数据完整性：比较
offset（复制偏移量），选偏移量最大者 —— 这代表它同步的数据最新 -
第四层确定性兜底：若多个节点 offset 相同，按
run_id字典序选最小的那个，确保结果可重现
注意：slave-priority 必须在从节点的 redis.conf 中显式配置并重启生效，仅在哨兵配置里写无效。
parallel-syncs 和 down-after-milliseconds 的隐性冲突
这两个参数表面无关，实则影响 failover 后的数据恢复质量：
-
sentinel parallel-syncs mymaster 1控制新主上任后，允许多少个从节点同时发起全量同步（SYNC）。值太大会压垮新主 IO；值为 1 则恢复慢 -
sentinel down-after-milliseconds mymaster 5000设得太短（如 1000ms），可能因瞬时网络延迟误判从节点下线，导致它在第二轮筛选中被第一层直接剔除 - 生产环境常见组合：
down-after-milliseconds设为 3000–6000，parallel-syncs设为 1–2，避免新主刚上任就陷入同步风暴
真正容易被忽略的是：failover 完成后，原主节点即使恢复，也**不会自动变回主节点**，它会以从节点身份重新加入，并尝试复制新主 —— 这个行为由哨兵自动重写 redis.conf 中的 slaveof 配置完成，无需人工干预，但前提是原主节点能连上新主且密码一致。
