down-after-milliseconds设太小会导致频繁误切，它触发主观下线（+sdown）而非直接切换，网络抖动、慢查询或tcp延迟易致误判，引发“准备切→发现没真挂→取消”震荡循环，日志表现为反复+sdown却无+odown。

down-after-milliseconds设太小会导致频繁误切

这个参数不是“等多久就切主”，而是“等多久才敢怀疑主挂了”。它触发的是主观下线（+sdown），一旦设得太小（比如 500 或 3000），网络瞬断、Redis 慢查询卡住事件循环、Linux TCP 栈偶发延迟，都可能让哨兵误标 +sdown。而其他哨兵还没到阈值，无法达成客观下线（+odown），整个流程就卡在“准备切→发现没真挂→取消”的震荡循环里。

真实生产中，60% 以上的长切换耗时，根源就是这种过早的 +sdown 导致重试 + sentinel_tilt=1 激活，而不是选举慢或同步慢。

• 局域网 RTT ≤ 15ms 的环境，设 down-after-milliseconds ＜ 8000，每天可能误切数次
• 跨机房链路或 Redis 负载偏高，设 5000 就极易引发雪崩式重选主
• 绝对不要低于 1000 —— 即使是本地回环，内核调度和 Redis 事件循环也可能单次 PING 超过 500ms

哨兵日志里反复出现+sdown但不升级为+odown

这是误设 down-after-milliseconds 最典型的表征：日志里不断刷 +sdown master mymaster，却始终不见 +odown 和 +switch-master。说明单个哨兵判定失败了，但其他哨兵没同步跟上——要么是 quorum 没凑够（比如配了 2，但只有 1 个哨兵超时），要么是网络分区导致哨兵间心跳（__sentinel__:hello）收不到，投票根本没法发起。

更隐蔽的情况是：某个哨兵因时钟漂移或 CPU 过载，进入 sentinel_tilt=1 状态，此时所有主观下线判定都会暂停，+sdown 日志也会停掉，但你查不到明显报错。

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

• 必须逐个连上每个哨兵端口（默认 26379），执行 SENTINEL CONFIG GET mymaster down-after-milliseconds 确认真实生效值
• 用 redis-cli -p 26379 info sentinel | grep num- 观察 num-down-sentinels 是否长期不等于 num-other-sentinels，这往往是网络分区信号
• 检查 ntpq -p 和 CPU 使用率，排除系统级异常

探测间隔与down-after-milliseconds不匹配会直接卡死流程

很多人以为调大 down-after-milliseconds 就能“降低轮询频率”，其实完全搞反了：哨兵对主节点的 PING 探测间隔由 sentinel monitor 的第四个参数控制（例如 sentinel monitor mymaster 127.0.0.1 6379 2 10000 中的 10000），和 down-after-milliseconds 无关。后者只影响“判定失败”的阈值。

但如果 down-after-milliseconds 小于探测间隔（比如探测是每 10 秒一次，而你设成 5000），哨兵可能第一次 PING 都没等到响应就直接判下线，根本没机会发第二次，导致判定极不稳定。

• 探测间隔必须 ≤ down-after-milliseconds ÷ 3，否则哨兵大概率连重试机会都没有
• 调大探测间隔（如从 10000 改为 30000）可降低开销，但必须同步把 down-after-milliseconds 提到至少 90000，否则服务恢复窗口会拉长到近一分钟
• 永远不要让 down-after-milliseconds 小于探测间隔——这是硬性约束，不是建议

failover-timeout设太小会让故障转移半途被abort

failover-timeout 和 down-after-milliseconds 常被一起调，但作用完全不同：down-after-milliseconds 控制“什么时候认为主挂了”，failover-timeout 控制“挂了之后整个切换流程最多忍多久”。前者太小会误判，后者太小会中止。

比如 down-after-milliseconds 设为 2000，网络抖动丢两个包就触发 failover 流程；但如果 failover-timeout 只有 10000，而新主同步、从库重连、客户端通知这些步骤加起来要 12 秒，那这次切换就会被 abort，日志里出现 +failover-abort-not-elected。

• 推荐将 failover-timeout 设为 down-after-milliseconds 的 3–5 倍（如前者是 8000，后者至少 24000，生产建议 40000）
• 别盲目追求“快”——两者都调小 ≠ 切换变快，只是让系统更“敏感”和更“急躁”，风险远大于收益
• 跨机房场景下，failover-timeout 必须覆盖新主全量同步 + 从库增量追平 + 客户端 DNS 缓存刷新的全部时间

真正卡住哨兵切换的，往往不是选举算法或网络带宽，而是这几个参数之间的时间逻辑没对齐。尤其是 down-after-milliseconds，它像一道闸门——设松了，水漫金山；设紧了，水流不过去。实际调参时，得先测 P99 RTT，再按比例推导，而不是抄别人配置。