redis哨兵故障转移分两阶段：先由≥quorum哨兵投票选出leader，再由leader按健康检查、优先级、offset、run_id四层规则筛选新主；原主恢复后自动降为从节点。

Redis哨兵模式的故障转移不是随机选一个从节点顶上，而是有明确的两阶段选举机制：先选一个领头哨兵（Leader Sentinel），再由它执行新主节点（new master）的筛选。跳过这个分步逻辑，直接调 SENTINEL failover 或改配置，大概率触发脑裂或选错节点。

sentinel failover 触发后实际发生了什么

手动执行 SENTINEL failover <master-name></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 配置完成，无需人工干预，但前提是原主节点能连上新主且密码一致。