Redis Sentinel故障恢复是严格时序的多层协同流程：先由单哨兵判定主观下线（SDOWN），再经quorum个哨兵共识达成客观下线（ODOWN），随后按优先级选举新主并原子化切换，最终通知客户端无感衔接。
Redis Sentinel 集群故障恢复不是“一触即发”的简单切换，而是一套有严格时序、多层校验、多方协同的自动流程。核心目标是：在主节点真实失效时快速响应，同时避免因网络抖动、临时卡顿等误判引发脑裂或重复切换。
主观下线（SDOWN）是起点，不是判决
每个 Sentinel 每秒向主节点发送一次 PING。若连续 down-after-milliseconds（默认 30000ms，即 30 秒）未收到 +PONG、-LOADING 或 -MASTERDOWN 响应，就将其标记为 SDOWN。
- 这只是单点判断，不触发任何动作
- 该值不宜过小：5000–10000ms 更适合低延迟生产环境；设太小（如 2000ms）易被慢查询、fork 阻塞或瞬时网络抖动误杀
- 它不控制心跳频率（固定 1 秒），只影响“超时判定窗口”
客观下线（ODOWN）才是故障转移的开关
多个 Sentinel 通过 Gossip 每 2 秒交换状态。当至少 quorum 个 Sentinel 都报告同一主节点为 SDOWN，该节点就被标记为 ODOWN。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- quorum 是可配置阈值（如
sentinel monitor mymaster 192.168.1.100 6379 2中的 2），不等于多数派，但建议设为哨兵总数的过半（3 节点设 2，5 节点设 3） - 只有 ODOWN 状态达成，才允许进入后续选举与切换流程
- 未达 quorum 时，即使某个 Sentinel 认为主挂了，也静默等待共识
新主选举有一套明确优先级规则
Leader Sentinel 在所有从节点中筛选候选者，按以下顺序逐级过滤：
- 排除断连过久者：与原主失联时间超过
down-after-milliseconds × 10的从节点直接淘汰 - 比 replica-priority：值越小越优先（0 表示永不参选）
- 比复制偏移量（offset）：越大说明数据越新，同步越完整
- 比 runid：ASCII 字典序最小者胜出（确定性兜底）
切换执行与客户端无感衔接
新主选定后，Leader Sentinel 会原子化完成三件事：
- 向当选从节点发送
SLAVEOF NO ONE，使其升为新主 - 向其余从节点广播
SLAVEOF <new_master_ip> <port>，重定向复制源 - 通过 Pub/Sub 或客户端订阅接口，将新主地址推送给接入的 Redis 客户端（如 Lettuce、Jedis Sentinel Pool）
客户端收到更新后，自动刷新连接池，后续写请求发往新主——整个过程对上层业务透明，通常在 10–30 秒内完成（取决于 down-after-milliseconds 和网络延迟）。
