主从切换慢主因是down-after-milliseconds设太小，导致频繁误判sdown、中断故障转移；应据p99 rtt×3设值（如8ms→24000），并同步调优parallel-syncs、failover-timeout和quorum。
主从切换慢，八成不是哨兵性能差，而是 down-after-milliseconds 设得太小，导致频繁误判、反复取消故障转移流程。
为什么改 down-after-milliseconds 能明显缩短切换耗时
这个参数不控制“什么时候切”，只控制“什么时候开始怀疑主挂了”。它触发的是主观下线（+sdown），后续还要走客观下线投票、选举、配置传播等环节。设得太小（比如 500 或 3000），一次网络瞬断、Redis 慢查询卡住事件循环、甚至 Linux TCP 栈偶发延迟，都会让哨兵误标 sdown；而其他哨兵还没到阈值，无法达成 odown，整个流程就卡在“准备切→发现没真挂→取消”循环里。
- 局域网稳定环境（RTT 5–15ms）：
down-after-milliseconds必须 ≥ 8000，否则每天可能触发数次误切 - 跨机房或含公网链路：
down-after-milliseconds直接设为 15000，别省那几秒 - 绝对不要低于 1000 —— 即使是本地回环，Linux 和 Redis 事件循环也可能偶发 >500ms 延迟
怎么测出合理的 down-after-milliseconds 值
不能拍脑袋设 5000 或 10000，得看真实链路的 P99 延迟分布。先用 redis-cli -h <master-ip> -p <master-port> --latency</master-port></master-ip> 测 5 分钟，观察输出里的 P95/P99 值；再查哨兵日志中 +sdown 出现前后的 PING 超时记录，确认是否集中在某个毛刺区间。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 若 P99 RTT 是 8ms，
down-after-milliseconds至少设为 8000（建议 ×3，即 24000） - 探测间隔（
sentinel monitor第四个参数）必须 ≤down-after-milliseconds÷ 3，否则哨兵可能连第二次 PING 都没发完就判定下线 - 调大该值后，务必同步检查
sentinel failover-timeout是否仍大于它的 3–5 倍，否则会频繁出现+failover-abort-not-elected
down-after-milliseconds 不是孤立参数，必须配平三个关键项
单独调它，大概率引发连锁问题。尤其注意这三项的时间逻辑必须对齐：
-
sentinel parallel-syncs：设为 1 最稳；设为 >1 可加快从库追平，但若新主 CPU 或网卡已近瓶颈，反而拖慢整体恢复 -
sentinel failover-timeout：必须 >down-after-milliseconds，推荐设为后者的 3–5 倍（如前者是 8000，后者至少 24000，推荐 40000） -
quorum（sentinel monitor第三个参数）：必须被至少quorum个哨兵同时判定为sdown才能升级为odown；若设为 1 且down-after-milliseconds过小，极易单点误触
真正卡住切换的，往往不是哨兵本身，而是参数之间的时间边界没对齐：怀疑起点太早、共识门槛太低、兜底时限又太短——系统既敏感又急躁，结果就是频繁 abort 和震荡。调参前，先抓包验证 PING 间隔、实测最慢从节点全量同步耗时、盯紧哨兵日志里的 +sdown/+odown/+switch-master 时间戳差值。
