哨兵跨机房延迟问题需同步调整down-after-milliseconds、failover-timeout、quorum三参数并验证仲裁链路：down-after-milliseconds取跨机房ping p99值的10–15倍；failover-timeout设为60000且≤down-after-milliseconds×2；quorum设为≥2且哨兵须跨机房部署；还需开启系统tcp_nodelay。
哨兵跨机房延迟问题不是“调高 timeout 就完事”，而是必须同步调整三个参数并验证仲裁链路是否真正跨机房生效。
down-after-milliseconds 设太高会导致故障发现慢，设太低会误判
这个参数决定哨兵多久没收到主节点 PING 就标记为 SDOWN（主观下线）。跨机房 RT 波动大（实测常达 20–80ms），若仍用默认的 30000（30 秒），一次网络抖动就可能触发误切换；但若盲目调低到 5000，又容易把短暂抖动当宕机。
实操建议：
- 先用
redis-cli -h sentinel-ip -p 26379 SENTINEL ping测各哨兵到主库的 PING 延迟，取 P99 值（比如 65ms） - 设为该值的 10–15 倍：如 P99 是 65ms，推荐设
down-after-milliseconds 1000（1 秒） - 必须确保所有哨兵节点配置一致，否则投票逻辑错乱
failover-timeout 决定脑裂窗口期，不能只看单次选举耗时
它控制两次故障转移之间的最小间隔，也影响从判定 SDOWN 到真正发起选举的等待时间。默认 180000（3 分钟）在跨机房场景下太长——网络闪断恢复后，旧主可能已写入新数据，而新主还没完成同步。
实操建议：
- 设为
60000（1 分钟）起步，配合min-replicas-to-write 1+min-replicas-max-lag 400使用 - 这个值必须 ≤ 所有哨兵节点的
down-after-milliseconds× 2，否则无法进入 ODOWN 投票阶段 - 修改后需执行
SENTINEL reset *清除缓存状态，否则旧配置仍生效
quorum 不是“多数派”数字，而是跨机房仲裁能力的硬门槛
很多人以为 sentinel monitor mymaster ip port 2 中的 2 表示“两个哨兵同意就行”，其实它代表“至少多少个哨兵能达成法定共识”。如果 3 个哨兵全在 A 机房，A 机房断网，哪怕 B 机房从节点完全健康，SENTINEL ckquorum mymaster 也会返回 NOQUORUM。
实操建议：
- 哨兵总数必须 ≥ 3，且至少 1 个部署在非主库所在机房（例如：A 机房放 2 个，B 机房放 1 个）
-
quorum设为 2（3 个哨兵时）或 3（4 个哨兵时），永远不要设为 1 —— 否则失去容错意义 - 每次变更后，用
SENTINEL sentinels mymaster确认各哨兵看到的其他哨兵 IP 是否包含跨机房地址
最容易被忽略的是：哨兵自身的 TCP 连接行为不受 tcp-nodelay 控制，它依赖系统级 net.ipv4.tcp_nodelay=1，且必须在所有哨兵机器上统一开启。否则即使参数调对了，PING 包仍被 Nagle 算法攒批发送，导致实际检测延迟翻倍。
