主库高负载导致哨兵误判主节点主观下线，根源在于down-after-milliseconds设值未适配P99 PING延迟与RTT，叠加quorum过低、客户端未动态刷新主地址，引发虚假故障转移。
主库高负载导致 PING 响应延迟超时
哨兵默认每秒向主节点发一次 PING，并依赖 down-after-milliseconds（默认 30000ms）判断是否响应超时。但这个超时是针对单次 PING 的——如果主库 CPU 打满、内存紧张或阻塞在大 key 删除、Lua 脚本、AOF fsync 等同步操作上，PONG 可能延迟几十甚至上百毫秒才返回。连续几次超时，单个哨兵就会标记为主观下线（SDOWN）。
这不是网络问题，而是主库自身处理能力饱和导致的“假死”信号。哨兵无法区分「真宕机」和「忙到没空回 ping」。
quorum 配置过低放大误判风险
当多个哨兵同时因高负载误判 SDOWN，只要达到 quorum 阈值（比如设为 1 或 2），就会触发客观下线（ODOWN）和故障转移——哪怕主库其实还在正常服务写请求。
quorum</em> 是触发 ODOWN 的最小同意哨兵数，不是哨兵总数；它不参与选举，只决定是否启动故障转移</li> <li>生产环境若只部署 3 个哨兵却把 <code>quorum
设为 1，等于任意一个哨兵误判就可能引发切换- 更危险的是：如果哨兵和主库部署在同一台机器，主库高负载时哨兵进程也可能被调度延迟，进一步恶化误判
从库复制积压加剧心跳失序
主库高负载常伴随 repl-backlog 积压、从库 master_repl_offset 落后，这本身不触发哨兵动作。但关键在于：哨兵会同时监控主从节点健康状态。当从库因复制慢而频繁断连重连，哨兵日志里会出现大量 +sdown / -sdown 来回抖动，干扰对主库真实状态的判断逻辑。
尤其当主库已开始慢查询，而哨兵又在反复尝试连接刚断开的从库时，其资源占用上升，反过来又拖慢对主库的探测频率与响应解析，形成负反馈循环。
客户端未启用 sentinel.get_master_addr_by_name() 动态刷新
即使哨兵没误切，主库高负载期间，部分客户端仍可能因连接池复用旧连接、DNS 缓存、或硬编码地址，持续往主库打读请求，进一步加重负载——这虽不直接导致虚假下线，但会让整个系统更接近误判临界点。
真实踩坑案例中，有团队发现哨兵日志里反复出现 +sdown master mymaster 10.0.1.100:6379 和 -sdown master mymaster 10.0.1.100:6379，查下来就是客户端没调用 sentinel.get_master_addr_by_name() 获取最新主节点，反而自己维护了一套失效的“主库地址缓存”，导致流量分布异常，主库雪上加霜。
最容易被忽略的一点：哨兵的 down-after-milliseconds 不是越长越好。设得太长（比如 60s），故障真实发生时切换延迟拉长；设得太短（比如 5s），又极易被瞬时负载抖动带偏。真正合理的值，得结合你主库的 P99 PING 延迟 + 网络 RTT 来定，而不是照搬默认值。
