哨兵通过“客观下线”（odown）判断主节点真挂了：单个哨兵连不上仅为主观下线（sdown），需至少quorum个哨兵达成一致才触发odown；哨兵间用sentinel is-master-down-by-addr命令确认，非心跳广播，网络分区可能导致结论不一。
哨兵怎么判断主节点“真挂了”
哨兵不会一发现主节点连不上就立刻切主，它得先确认是不是真的故障——这个叫“客观下线”（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。
