哨兵集群超时参数需闭环匹配：基于实测p99 rtt（如72ms）设down-after-milliseconds≈1000，显式配置sentinel monitor第四参数（如3000），确保≥2倍探测间隔；failover-timeout建议60000且≤down-after-milliseconds×2；禁用域名、强制ip；修改后sentinel reset *并验证ckquorum。
哨兵集群心跳超时参数配得不对，故障发现慢或误切主库就是分分钟的事——关键不是调大或调小，而是让 down-after-milliseconds、sentinel monitor 探测间隔、failover-timeout 三者形成闭环匹配，且必须基于真实跨节点 RTT 数据。
先测真实 PING 延迟，别信默认值
所有超时参数的起点是实测延迟。跨机房部署下，redis-cli -h <sentinel-ip> -p 26379 SENTINEL ping</sentinel-ip> 单次结果没意义，要跑够 5 分钟，用 redis-cli --latency-history -h <sentinel-ip> -p 26379</sentinel-ip> 抓 P99 RTT（比如实测是 72ms）。
- 这个值决定了你能不能把
down-after-milliseconds设到 1000（72 × 14 ≈ 1008），而不是沿用默认的 30000 - 如果 P99 RTT 超过 150ms，说明网络已不可靠，该优先查丢包、中间设备限速，而非硬调参数
- 务必在所有哨兵节点上分别测，取最大 P99 值作为基准，不能只测一个
显式配置 sentinel monitor 的第四个参数
很多人写 sentinel monitor mymaster 10.0.1.100 6379 2，漏掉探测周期，结果哨兵仍按默认 10 秒发 PING，但 down-after-milliseconds 却设成了 5000，导致刚发一次 PING 就判定 SDOWN。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须显式加第四个参数：
sentinel monitor mymaster 10.0.1.100 6379 2 3000表示每 3 秒探一次 - 强制满足：
down-after-milliseconds ≥ 2 × 探测间隔，否则探测逻辑失效 - 改完后执行
SENTINEL MONITOR mymaster 10.0.1.100 6379 2 3000热重载（Redis 6.2+ 支持），不重启也能生效
failover-timeout 不是“等多久再切”，而是仲裁窗口底线
这个参数常被误解为“故障转移耗时上限”，其实它控制的是：从第一个哨兵标记 SDOWN 开始，到允许发起 ODOWN 投票之间，必须经过的最小时间窗口。
- 设太小（如 10000）会导致网络抖动时多个哨兵抢着发起选举，出现脑裂风险
- 设太大（如 300000）会让真实故障卡在 SDOWN 状态迟迟无法进入投票，客户端持续写旧主
- 生产建议值：
failover-timeout 60000，且必须 ≤ 所有哨兵节点的down-after-milliseconds × 2，否则SENTINEL ckquorum mymaster会返回 NOQUORUM - 修改后必须执行
SENTINEL reset *清除缓存状态，否则旧值仍参与投票计算
禁用域名解析 + 强制使用 IP 是硬性前提
只要 sentinel monitor 里用了域名，哪怕配置了 sentinel resolve-hostnames no，Redis 6.2+ 在某些 glibc 版本下仍可能触发 getaddrinfo() 阻塞，单次探测延迟飙升到秒级，直接拖垮整个判定链路。
- 全部改用 IP：
sentinel monitor mymaster 10.0.1.100 6379 2 3000，别碰域名 - 检查配置是否被覆盖：
redis-cli -p 26379 CONFIG GET "sentinel resolve-hostnames"，输出必须是"no" - 改完必须重启哨兵进程，热重载不生效 —— 这个限制容易被忽略
最常被跳过的动作是：改完参数后没清哨兵状态缓存，也没验证 SENTINEL ckquorum mymaster 是否返回 OK；还有人把哨兵全堆在一个机房，却指望 quorum 2 能跨机房仲裁——这些细节不卡死，再准的超时参数也白搭。
