主观下线（SDOWN）是单个哨兵因PING超时独立判定的临时状态，客观下线（ODOWN）需至少quorum个哨兵通过SENTINEL is-master-down-by-addr确认一致才触发故障转移；二者不可混淆，quorum配置不当、down-after-milliseconds不一致或网络分区易致误判。
主观下线（sdown）和客观下线（odown）不是一回事
哨兵不会一连不上就切主，它先标记 sdown（主观下线），再靠其他哨兵确认是否真挂了——这个确认过程叫 odown（客观下线）。sdown 是单点判断，odown 才是触发故障转移的门槛。误判往往卡在第一步：某个哨兵自己网络抖动、延迟高或负载大，PING 超时就标 sdown，但它还没来得及广播或被其他哨兵采信，日志里却已出现“+sdown master mymaster”，容易让人误以为系统要切主了。
down-after-milliseconds 配置不一致最常引发误判
每个哨兵的 sentinel down-after-milliseconds 值必须完全一致。如果 A 哨兵设为 5000ms，B 设为 30000ms，A 在主节点慢查询堆积时早早就标 sdown，而 B 还在等——结果就是 A 认为该投票，B 压根不响应 SENTINEL is-master-down-by-addr 请求，导致 odown 永远无法达成。排查时别只看配置文件，要用 SENTINEL CONFIG GET down-after-milliseconds 在每台哨兵上实测读取值。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
网络分区或主节点假死才是真凶
主节点没宕机，但复制积压严重、INFO 命令响应超时、或 TCP 连接卡在 SYN_RECV 状态，都会让哨兵收不到合法 PING 回复。此时 sdown 是真实现象，但不是“宕机”。常见诱因包括：
- 主节点正在执行
SAVE或BGSAVE，阻塞主线程超过down-after-milliseconds - 主节点
maxmemory触发淘汰策略，大量 key 过期扫描拖慢响应 - 主机网卡打满、软中断不均、或云厂商安全组限速导致 PING 包丢一半
- 主节点所在机器 NTP 偏移 > 5s，哨兵间 hello 消息时间戳校验失败，视图分裂
quorum 设置过小会放大误判影响
quorum 不是容错数，而是最小同意数。3 个哨兵配 quorum 1，等于允许任意一个哨兵“拍板”就进 odown；哪怕它刚从网络分区恢复、缓存了旧状态、或本机磁盘 IO 高导致命令排队。这种配置下，一次瞬时超时就能触发完整故障转移流程，后续还得靠人工回滚。真正安全的底线是 quorum = 2（3 哨兵）或 quorum = 3（5 哨兵），且必须确保所有哨兵能双向互通 26379 端口——防火墙漏掉一条规则，就可能让部分哨兵永远收不到 hello，变成“幽灵哨兵”，它们既不参与投票，也不报错，只默默旁观整个误判过程。
