Redis哨兵故障转移全过程解析

本文深入剖析了Redis哨兵（Sentinel）故障转移的完整流程与关键细节，从如何通过“主观下线”（SDOWN）与“客观下线”（ODOWN）机制精准判断主节点真实故障，到基于优先级、数据新鲜度和运行ID的科学选主策略；既揭示了网络分区、quorum配置不当、protected-mode拦截等常见导致Failover卡住或失败的隐性陷阱，也直击客户端命令丢失、从节点同步失败等生产环境高频痛点，并给出可落地的配置建议与排障思路——帮你避开教科书式理解与线上事故之间的巨大鸿沟。

哨兵怎么判断主节点“真挂了”

哨兵不会一发现主节点连不上就立刻切主，它得先确认是不是真的故障——这个叫“客观下线”（ODOWN）。单个哨兵连不上，只算“主观下线”（SDOWN）；只有足够多的哨兵（由 quorum 配置决定）都报告 SDOWN，才会升级为 ODOWN。

• quorum 不是投票数，而是“触发故障转移所需的最小同意哨兵数”，哪怕你部署了 5 个哨兵，quorum 设成 2，只要 2 个认为主挂了，就进入 ODOWN 状态
• 哨兵之间通过 SENTINEL is-master-down-by-addr 命令互相确认，不是靠心跳广播，所以网络分区时可能不同集群得出不同结论
• 如果哨兵自己和多数派失联（比如只剩 1 个能通信），它会拒绝发起 Failover，避免脑裂——这点常被忽略，配置 quorum 时没考虑哨兵节点数，会导致永远卡在 SDOWN

Failover 触发后，选谁当新主节点

不是随便挑个从节点顶上，哨兵有一套明确的打分规则，按顺序淘汰：

• 排除掉 sentinel down-after-milliseconds 内连续失败的从节点（比如刚断连过，状态不稳）
• 优先选 slave-priority 值小的（默认 100，可配成 10/5/1 来指定偏好）
• 再比复制偏移量（offset），越接近原主的数据越新，得分越高
• 最后比 runid 字典序——纯保底，实际中应靠前两项控制，否则容易每次选不同节点，增加客户端重连抖动

注意：slave-read-only yes 是默认值，但如果你手动改过从节点为可写，哨兵仍会把它当候选主节点，只是后续数据同步会出问题——这不是 Failover 失败，而是数据一致性风险，得靠配置守牢。

切换过程中客户端会不会丢命令

会，而且大概率丢。Redis 哨兵 Failover 本身不提供原子性保障，整个过程分三步：原主下线 → 新主选出并配置 → 客户端重定向。中间存在时间窗口：

• 原主在收到 FAIL 命令后，可能还在处理请求，但已不再接受新连接，未响应的请求会超时或被客户端丢弃
• 新主刚提升时，会执行 SLAVEOF NO ONE，然后等待所有从节点重新同步，这期间它不拒绝写入，但若此时有客户端直连旧主地址（还没收到重定向），命令就彻底丢失
• 客户端 SDK 是否支持 +switch-master 事件监听很关键：Jedis 需要启用 setMasterDownAfterMilliseconds 并监听 Pub/Sub，Go 的 redis-go 默认不自动重连新主，得自己捕获 MOVED 或 ASK 错误重试

为什么 Failover 后有时从节点连不上新主

常见于配置残留或角色未刷新。哨兵改完主从关系后，会向所有参与节点发送 CONFIG REWRITE 和 SLAVEOF，但某些情况会失败：

• 从节点设置了 protected-mode yes 且没配 bind 或 requirepass，导致哨兵发来的 SLAVEOF 被拒绝（错误日志里会出现 NOAUTH Authentication required）
• 原主节点其实没彻底宕机，只是假死，重启后自认还是主，拒绝从节点的 PSYNC 请求，报错 Can't SYNC while not connected with my master
• 哨兵配置里 sentinel monitor 的主节点 IP 写的是内网地址，而从节点用公网 DNS 解析，导致 SLAVEOF 发过去的是错的地址，连不上

最麻烦的是第三种：现象是“新主正常，但从节点一直连不上”，查日志全是 timeout，但 telnet 又通——这时候得翻哨兵的 sentinel.conf 里 monitor 行写的到底是什么地址，而不是只看 redis.conf。

到这里，我们也就讲完了《Redis哨兵故障转移全过程解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！