根本原因是哨兵间通信中断导致无法达成共识：SENTINEL ckquorum报missing+quorum即表明在线且互通的哨兵数小于quorum值，如配置quorum=2但仅1台可达，则直接卡死不进入投票；须双向打通26379端口、校准NTP偏移≤5s、禁用rename-command CONFIG会彻底破坏协商。
Redis 哨兵无法选出 Leader 节点，根本原因不是“投票失败”，而是哨兵集群自身无法达成 Raft-like 共识——多数哨兵之间连基本通信都中断了，压根走不到投票那步。
SENTINEL ckquorum 报 missing+quorum 是什么信号
这个输出不是警告，是判决书：当前在线且能互相通信的哨兵数 quorum 值。比如配置了 sentinel monitor mymaster 127.0.0.1 6379 2，但只有 1 台哨兵响应 SENTINEL ckquorum mymaster，就直接卡死，不触发任何故障转移流程。
- 必须双向打通所有哨兵的
26379端口（不仅是入站，出站也要放行） - 用
telnet other-sentinel-ip 26379逐台测试连通性，别只 ping IP - NTP 时间偏移 > 5s 会导致 hello 消息被丢弃，
ntpq -p必查 - 如果某哨兵刚重启，需等待至少
default-down-after-milliseconds * 2（默认 60 秒）才能参与协商
SENTINEL sentinels 输出不一致说明什么
执行 SENTINEL sentinels mymaster 在不同哨兵上返回结果不同（有的为空、有的有 2 个节点、有的显示 down），说明 sentinel monitor 配置未同步完成。哨兵不读配置文件里的静态定义，靠 hello 广播动态协商，网络抖动或防火墙拦截会让部分节点掉队。
- 不要改完
sentinel.conf就以为生效，必须在每台哨兵上手动执行：SENTINEL monitor mymaster <ip><port><quorum></quorum></port></ip> - 执行后立刻跑
SENTINEL ckquorum mymaster和SENTINEL masters验证一致性 - 检查是否误启用了
rename-command CONFIG ""—— 哨兵内部依赖CONFIG GET/SET同步状态，禁用后协商彻底失能
为什么新哨兵加入后长期不参与选举
新哨兵启动后不会立即加入现有视图，它先以“观察者”身份收集其他哨兵发来的 hello 消息，直到确认自己收到足够多的有效广播（默认需 30 秒内收齐），才正式进入投票池。这期间 SENTINEL sentinels 可能完全看不到它。
- 新哨兵上线后，等满 30 秒再查
SENTINEL sentinels mymaster，别刚启动就急着验证 - 用
redis-cli -p 26379 INFO sentinel查sentinel_masters和sentinel_running_scripts，确认是否已加载监控目标 - 如果日志里反复出现
+sdown sentinel，说明它和其他哨兵的 26379 端口不通，不是“慢”，是“断”
真正卡住选举的，从来不是算法复杂度，而是最底层的 TCP 连通性、时间同步、命令可用性——这三样没对齐，Raft 再严谨也投不出一票。
