Redis哨兵误判Master下线，主因是down-after-milliseconds设太小、quorum配太低或failover-timeout未对齐：前者致频繁+sdown，后者引发单点误触或切换中断，三者时间边界错位会导致反复“准备切→取消”。
Redis哨兵误判Master下线，八成不是哨兵本身坏了，而是 down-after-milliseconds 设得太小、quorum 配得太低、或 failover-timeout 没对齐——三者时间边界一错，系统就既敏感又急躁，反复“准备切→发现没真挂→取消”。
down-after-milliseconds 值太小导致频繁+sdown
这个参数决定单个哨兵在多久没收到主节点 PING 回复后标记为“主观下线（+sdown）”。默认 30000 毫秒（30 秒）偏保守，但很多人手动改成 5000 甚至 1000，结果网络抖动一次、Redis 慢查询卡住事件循环几十毫秒，就触发+sdown。
- 局域网稳定环境：实测 P99 RTT 若为 8ms，
down-after-milliseconds至少设为24000（3×P99），推荐8000起步 - 跨机房或含公网链路：直接设为
15000，别省那几秒 - 绝对不要低于
1000——Linux TCP 栈或 Redis 事件循环偶发延迟可能超 500ms - 探测间隔（
sentinel monitor第四个参数）必须 ≤down-after-milliseconds ÷ 3，否则哨兵可能连第二次 PING 都没发完就判定下线
quorum 设置过低引发单点误触
quorum 是“达成客观下线（+odown）所需最小哨兵数”，不是哨兵总数，也不自动同步。设为 1（默认值）等于把投票权交给任意一个哨兵，只要它那一次 PING 恰好超时，故障转移就启动了——而原主节点可能 2 秒后就恢复了。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 部署 3 个哨兵：
quorum应设为2（即 ⌊3/2⌋ + 1） - 部署 5 个哨兵：设为
3；设成1或5都不合理 - 务必确认
quorum≤ 当前在线哨兵数，否则日志里反复出现+sdown却始终没有+odown - 修改后需执行
SENTINEL SET mymaster quorum 2生效，且要逐节点操作
failover-timeout 与 parallel-syncs 时间逻辑断裂
failover-timeout 不是“切换要花多久”，而是“整个故障转移流程允许的最长窗口”。它必须覆盖从+sdown、投票、选主、重配从库到通知客户端的全过程。若它比 down-after-milliseconds 小，或没留够从库同步时间，就会频繁报 +failover-abort-not-elected 或卡在 reconfiguring slaves。
-
failover-timeout必须 >down-after-milliseconds，推荐设为后者的 3–5 倍（如前者是8000，后者至少24000，建议40000） -
parallel-syncs控制同时重配多少从库，默认1最稳；设为 >1 可加快同步，但若新主 CPU 或网卡已近瓶颈，反而拖慢整体恢复 - 检查从库是否真实可用：
redis-cli INFO replication中connected_slaves必须 ≥ 1，否则 Sentinel 根本无法完成切换
真正容易被忽略的是：这些参数不是独立生效的。调大 down-after-milliseconds 却忘了同步拉高 failover-timeout，或改了 quorum 却没验证当前在线哨兵数是否达标，问题只会从“误切”变成“不切”。时间边界对齐比单点调优重要得多。
