down-after-milliseconds 不是触发故障转移的开关，仅决定哨兵何时标记主节点为主观下线（SDOWN）；完成自动切换需满足 quorum 票数达成客观下线（ODOWN），再经选举和 failover-timeout 窗口内执行完整流程。
sentinel down-after-milliseconds 不是“触发故障转移”的开关，它只决定单个哨兵何时标记主节点为主观下线（SDOWN）。真要完成自动切换，得靠后续的客观下线投票、领导者选举和 failover-timeout 内的执行流程。
为什么改了 down-after-milliseconds 主库挂了却不切？
常见现象：主节点实际宕机，但 Sentinel 日志里只有 +sdown，迟迟不见 +odown 和 +switch-master。这说明主观下线没凑够 quorum 票数 —— 可能是其他哨兵还没到阈值，或网络分区导致通信失败。
-
quorum值必须被至少quorum个哨兵同时判定为SDOWN，才会升级为ODOWN - 如果
down-after-milliseconds设得过大（比如 60000），而你的网络 P99 RTT 是 12ms，那一次真实故障可能要等满 60 秒才开始走投票流程 - 如果设得太小（比如 500），瞬时网络抖动或 Redis 慢查询卡住事件循环，就会频繁触发
SDOWN→ 多数哨兵不认同 → 反复取消，反而拖慢恢复
down-after-milliseconds 和 failover-timeout 怎么配才不翻车？
这两个参数不是独立调优项，它们构成故障响应的“起始”与“兜底”边界。设错一个，另一个就容易失效。
-
down-after-milliseconds应 ≥ 实际链路 P99 延迟 × 3（例如内网 P99=8ms → 至少设 8000） -
failover-timeout必须 >down-after-milliseconds，且建议为它的 3–5 倍（如前者是 8000，后者至少 24000，推荐 40000） - 若跨云厂商或含公网链路，直接设
down-after-milliseconds= 15000，failover-timeout= 180000，别省那几秒 - 绝对不要把
failover-timeout设得比down-after-milliseconds还小 —— 那等于告诉哨兵：“你还没确认主挂了，我就要超时了”
parallel-syncs 改大了，切换反而更慢？
这个参数控制故障转移后，有多少从节点能并发地从新主同步数据。但它直接影响新主的 CPU 和带宽压力，尤其在主库本身负载已高的时候。
- 设为
1：最稳，但所有从库串行同步，总耗时长 - 设为
3或更高：加速同步，但如果新主网卡打满或 CPU 负载 >70%，会导致REPL_TIMEOUT，部分从库反复重连，延长整体恢复窗口 - 生产环境建议先观察正常主从复制时的
repl_backlog_size和从库master_repl_offset差距，再决定是否调高parallel-syncs
真正卡住自动故障转移的，往往不是哨兵性能，而是参数之间的时间逻辑没对齐 —— down-after-milliseconds 定义怀疑起点，quorum 决定共识门槛，failover-timeout 给出操作窗口，三者缺一不可。线上调参前，务必用 redis-cli -p 26379 info sentinel 看当前各哨兵的 sentinels 数量和 myid 是否一致，避免配置漂移。
