哨兵判定主节点“客观下线”失败的常见现象是客户端连接断开、写请求超时，但 sentinel info 显示 master-status:ok 或 sentinels 数量不足，本质是哨兵未达成 quorum 票数共识；原因包括 quorum 设置过大、哨兵间 26379 端口不通、monitor 配置不一致等。
哨兵判定主节点“客观下线”失败的常见现象
客户端连接突然断开、写请求超时，但 redis-cli -p 26379 info sentinel 显示主节点仍被标记为 master-status:ok，或 sentinels 数量少于预期 —— 这往往不是 Redis 实例挂了，而是哨兵之间没达成共识。
根本原因在于：单个哨兵触发 SDOWN（主观下线）很容易，但必须有 ≥ quorum 个哨兵也报告该主节点失联，才能升级为 ODOWN（客观下线）并启动选举。若哨兵间通信延迟高、丢包或配置不一致，就卡在“多数派无法确认”这一步。
-
quorum值设得过大（比如 3 个哨兵却配成quorum 3），实际只要 1 个哨兵网络抖动，就永远凑不够票数 - 哨兵之间未互通
port（默认 26379）或防火墙拦截了 TCP 连接，sentinel known-sentinel查不到其他哨兵 - 各哨兵配置的
sentinel monitor中主节点地址不统一（如混用 IP 和域名、或端口写错），导致它们监控的是“逻辑上不同的主节点”
检查哨兵集群连通性与状态同步
先确认哨兵是否真的组成了集群，而不是各自为战：
在任一哨兵节点执行：
redis-cli -p 26379 sentinel masters
看返回的 num-sentinels 是否等于你部署的哨兵总数；再执行：
redis-cli -p 26379 sentinel sentinels mymaster
（mymaster 替换为你配置的 master-name）检查每个已知哨兵的 flags 字段 —— 正常应含 disconnected 以外的状态，且 last-ping-sent 和 last-ok-ping-reply 时间差不应超过 1 秒。
- 若
last-ping-sent很大但last-ok-ping-reply为空，说明该哨兵收不到其他哨兵的响应，优先查本机telnet26379 - 若
flags含odown但num-sentinels明显偏少，可能是部分哨兵启动时没加载正确配置，或--sentinel参数漏加 - 注意：哨兵之间使用 TCP 长连接，不依赖 Redis 主从复制通道，别误用
redis-cli -p 6379测试
故障转移卡在“选举领导者”阶段的典型日志线索
当主节点宕机后，哨兵日志中反复出现类似以下内容，就是选举受阻：
+odown master mymaster 192.168.2.20 6379 #quorum 2/3
—— 表示当前只有 2 票认可 ODOWN，但需要 3 票才够；而最后一行 +failover-abort-no-good-slave 实际是误导，真正拦住选举的是前面那句“票数不足”。
- 不要急着调
sentinel failover-timeout，它只控制单次选举耗时上限，解决不了投票失败根源 - 检查所有哨兵的
sentinel monitor mymaster ... quorum配置是否完全一致（尤其注意空格和大小写） - 如果哨兵跨公网或高延迟网络部署，把
sentinel down-after-milliseconds调大（如从 5000 改为 15000），避免因瞬时抖动触发误判
真实环境中最容易被忽略的网络配置点
很多团队在容器或云主机上部署哨兵后故障转移变慢甚至失败，问题不在 Redis 本身，而在底层网络假设被打破：
- 哨兵默认通过
INFO replication获取从节点 IP，若从节点运行在 Docker 内且未配置bind或announce-ip，哨兵拿到的是容器内网 IP（如172.17.0.3），其他哨兵根本连不上 - 云厂商安全组常默认放行入方向，但限制出方向 —— 哨兵 A 能连哨兵 B，B 却连不回 A，导致心跳单向成功，状态不同步
- Kubernetes 中若哨兵用 HostNetwork 模式，需确保
hostPort与配置文件中监听端口严格一致，否则sentinel known-sentinel显示的地址是错的
验证方式很简单：在哨兵 A 上执行 telnet ，再反向执行一次 —— 必须双向通。
