down-after-milliseconds 设值过小是主从切换慢的主因，它触发主观下线而非直接切换；合理值需基于 P99 网络延迟设定，并协同调整 parallel-syncs、failover-timeout 和 quorum 参数。
主从切换慢，八成是 down-after-milliseconds 设得太小，或网络抖动没被过滤掉，而不是哨兵本身性能问题。
为什么改 down-after-milliseconds 能明显缩短切换耗时
这个参数不是“等多久才切”，而是“等多久才开始怀疑主节点挂了”。它触发的是主观下线（sdown），后续还要走客观下线（odown）投票、选举、故障转移脚本执行等流程。设得太小（比如默认 30ms 或 100ms），网络瞬断、CPU 短暂打满、慢查询阻塞都会误触发，哨兵反复进入“准备切换→发现没真挂→取消”的状态，反而拉长整体恢复时间。
实际观察中，多数生产环境的主从切换延迟集中在 10–30 秒，其中 60% 以上源于过早的主观下线判断，而非选举或配置同步慢。
- 它只影响单个哨兵对主节点的健康判断，不控制投票或切换逻辑
- 值太小 → 频繁误判 → 多次重试 + TILT 模式风险上升
- 值太大 → 真故障时响应滞后，但只要大于网络 P99 延迟，就基本不会丢服务
down-after-milliseconds 的合理取值范围
不能拍脑袋设成 5000 或 10000，得结合你的真实链路延迟分布来定。先用 redis-cli -h <master-ip> -p <master-port> --latency</master-port></master-ip> 测 5 分钟，看 P95 和 P99 值；再查哨兵日志里 +sdown 出现前后的 PING 超时记录。
- 局域网稳定环境（RTT
- 跨机房/云厂商内网（RTT 5–15ms）：必须 ≥ 8000，否则每天可能触发数次误切
- 有公网链路或高负载 Redis 实例（慢查询多）：直接设为 15000，同时配合
sentinel failover-timeout控制最大切换窗口 - 绝对不要低于 1000 —— 即使是本地回环，Linux TCP 栈和 Redis 事件循环也可能偶发 >500ms 延迟
光调 down-after-milliseconds 不够，还得配平三个关键参数
单独改一个参数，容易引发连锁反应。尤其注意这三项必须协同调整：
-
sentinel parallel-syncs：故障后允许多少个从节点并行同步新主。设为 1 最稳，设为 >1 可加快从库追平速度，但会压新主带宽 —— 如果主库 CPU 或网卡已近瓶颈，反而拖慢整个切换完成时间 -
sentinel failover-timeout：单次故障转移允许的最长时间（毫秒）。它控制选举超时、从库升级等待、配置传播等环节总和。建议设为down-after-milliseconds的 3–5 倍，比如前者是 5000，后者至少 15000 -
sentinel monitor第四个参数（quorum）：触发客观下线所需的最小哨兵同意数。奇数哨兵集群（如 3 台）设为 2；5 台建议设为 3。设太高（如 5 台设 5）会导致投票失败，切换卡在+odown阶段不动
容易被忽略的底层干扰点
很多团队调完参数仍遇到“明明设了 5 秒，却 20 秒才切”，最后发现是这些地方在拖后腿：
- 哨兵进程本身 CPU 使用率持续 >70%：会导致
sentinelTimer定时任务延迟执行，PING 心跳发送不准，间接拉长sdown判定时间 - Redis 主实例正在执行
BGSAVE或AOF rewrite：会阻塞主线程，导致对哨兵 PING 回复超时，哪怕down-after-milliseconds设得再大也扛不住 - 哨兵配置文件里没开
protected-mode no（当哨兵跨网段部署时）：会导致订阅连接（__sentinel__:hello频道）建立失败，客观下线无法达成，切换永远卡住 - 使用了旧版哨兵（Redis down-after-milliseconds 实际生效值可能偏差 30% 以上 —— 必须升到 Redis 2.8+ 的 Sentinel 2
真正影响切换耗时的，从来不是“哨兵有多快”，而是“它有没有被逼着反复重试”。把误判源头堵住，再让各环节参数彼此咬合，10 秒内完成主从切换是完全可预期的常态，而不是需要祈祷的例外。
