down-after-milliseconds 应设为链路p99延迟的10–15倍且不低于8000（局域网）或15000（跨机房），并同步调整failover-timeout（3–5倍）、parallel-syncs（建议1）、quorum（n/2+1），修改后必须执行sentinel reset *清空状态缓存。
down-after-milliseconds 设太小会导致“假切换”反复中止
这不是检测慢，而是检测太急——down-after-milliseconds 触发的是主观下线（+sdown），不是真正切换。设成 3000 或 5000，一次 Redis 慢查询卡住事件循环 1.2 秒、或 Linux TCP 栈偶发延迟 800ms，就可能让某个哨兵提前标 sdown；但其他哨兵还没到阈值，无法达成 odown 投票，整个故障转移流程就被强制 abort，日志里反复出现 +failover-abort-not-elected。
真实生产中，60% 以上的长耗时切换，根源是这个参数过小引发的震荡，而非选举或同步本身慢。
- 局域网稳定环境（RTT ≤ 15ms）：必须 ≥
8000，否则每天可能误切数次 - 跨机房或含公网链路：直接设为
15000，别省那几秒 - 绝对不要低于
1000—— 即使是本地回环，Linux 调度和 Redis 事件循环也可能单次超 500ms
必须同步调的三个配套参数，缺一不可
down-after-milliseconds 不是孤立存在的。单独调大它，大概率引发连锁问题：怀疑起点太早、共识门槛太低、兜底时限又太短，系统既敏感又急躁。
-
sentinel failover-timeout：必须 >down-after-milliseconds，推荐设为后者的 3–5 倍。例如前者是8000，后者至少24000，更稳妥用40000。它控制整个流程总窗口，包括选举、从库升级、配置传播；设太小会频繁 abort -
sentinel parallel-syncs：建议设为1最稳；设为 >1（如2或3）可加快从库追平，但若新主 CPU 或网卡已近瓶颈，反而拖慢恢复 -
quorum（sentinel monitor第三个参数）：3 个哨兵建议设为2；5 个哨兵设为3。值太小易脑裂，太大则响应滞后
怎么测出你该用多少毫秒，而不是拍脑袋
不能凭经验设 5000 或 10000，得看真实链路的 P99 延迟分布：
- 先用
redis-cli -h <master-ip> -p <master-port> --latency</master-port></master-ip>测 5 分钟，观察输出里的 P95/P99 值 - 再查哨兵日志中
+sdown出现前后的 PING 超时记录，确认是否集中在某个毛刺区间 - 探测间隔（
sentinel monitor第四个参数）必须 ≤down-after-milliseconds ÷ 3，否则哨兵可能连第二次 PING 都没发完就判定下线
例如实测 P99 是 65ms，按 10–15 倍原则，down-after-milliseconds 推荐 1000（1 秒）起步；若探测间隔设为 3000，那 down-after-milliseconds 至少得是 9000。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
改完必须重置哨兵状态，否则旧配置还在生效
修改配置后，仅 reload 配置文件或重启哨兵节点是不够的。哨兵内部缓存了各节点的状态（比如是否已标记 sdown、上次投票结果等），不清理就会沿用旧判断逻辑。
必须执行：
redis-cli -p 26379 SENTINEL reset *
这条命令会清空所有哨兵节点的本地状态缓存，让它们重新开始探测和投票。否则即使参数改对了，也可能继续走老路径，切换依然超时。
最容易被忽略的点是：时间参数之间没对齐，以及改完不重置状态。这两件事不做，调再多次 down-after-milliseconds 都白搭。
