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 缓存和数据结构管理技能。通过自然语言操作 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></port></new_master_ip>,重定向复制源 - 通过 Pub/Sub 或客户端订阅接口,将新主地址推送给接入的 Redis 客户端(如 Lettuce、Jedis Sentinel Pool)
客户端收到更新后,自动刷新连接池,后续写请求发往新主——整个过程对上层业务透明,通常在 10–30 秒内完成(取决于 down-after-milliseconds 和网络延迟)。










