Redis哨兵

文章目录

  • [Redis Sentinel:Leader 选举与选主流程详解](#Redis Sentinel:Leader 选举与选主流程详解)
  • [Redis Sentinel:从主观下线到选出新主节点](#Redis Sentinel:从主观下线到选出新主节点)
    • [一、前提:为什么必须先选 Leader?](#一、前提:为什么必须先选 Leader?)
    • [1. 第一个哨兵:发现主节点挂了](#1. 第一个哨兵:发现主节点挂了)
    • [二、Leader 选举:完整过程](#二、Leader 选举:完整过程)
    • [2. 第一个发现的哨兵:推选自己当 Leader](#2. 第一个发现的哨兵:推选自己当 Leader)
      • [2.1 触发时机](#2.1 触发时机)
      • [2.2 选举的核心机制](#2.2 选举的核心机制)
    • [3. 其他哨兵:陆续发现,表示赞同](#3. 其他哨兵:陆续发现,表示赞同)
      • [2.3 选举过程时序](#2.3 选举过程时序)
    • [4. Leader 选出新主节点](#4. Leader 选出新主节点)

Redis Sentinel:Leader 选举与选主流程详解

Redis Sentinel:从主观下线到选出新主节点

主节点被判定为**客观下线(ODOWN)**之后,Sentinel 要做两件关键的事:

当一个哨兵发现主节点挂了,这时为主观下线;第一个发现下线的哨兵就推选自己作为 Leader,负责选出一个新的主节点;若其他节点后续也发现主节点挂了,就会赞同这个哨兵作为 Leader,选举出一个主节点。

  1. 在 Sentinel 集群里选举出一个 Leader
  2. 由这个 Leader 从从节点中挑选一个,提升为新 Master
    本文只聚焦这两条主线,其余能力(监控、通知、客户端发现等)一笔带过。

一、前提:为什么必须先选 Leader?

1. 第一个哨兵:发现主节点挂了

一个 Redis 主从集群可能部署多个 Sentinel 实例。若主节点挂了,不能 让每个 Sentinel 各自挑一个从节点升主------否则会出现多个 Master,数据立刻分裂。

Sentinel 会定期向主节点发心跳。某个哨兵(比如 S1)在约定时间内收不到回复,就会判定:主节点主观下线(SDOWN) 。

因此规则是:

这里的「主观」指的是:只有 S1 自己认为主节点挂了,别的哨兵此时可能还没发现。

  • 所有 Sentinel 都可以参与「发现故障、讨论谁下线」
  • 但整个 Failover 周期内,只有一个 Leader Sentinel 有权执行升主操作
    其余 Sentinel 只负责监控、投票、同步状态,不执行 SLAVEOF NO ONE 等切换命令。

二、Leader 选举:完整过程

2. 第一个发现的哨兵:推选自己当 Leader

2.1 触发时机

S1 既然已经认定主节点不可用,就不会干等着。它会推选自己作为 Leader ,准备接手后续工作:

Leader 选举只在主节点已被标记为 ODOWN 时才会发生。

  • 从还在线的从节点里,按规则挑一个
  • 把它提升为新的主节点
    简单回顾 ODOWN 是怎么来的(只为理解触发条件):
    此时 Failover 流程已经由 S1 发起,但还需要其他哨兵认可。
阶段 含义
SDOWN 某个 Sentinel 单独认为某节点超时无响应
ODOWN 足够数量 的 Sentinel 都同意主节点 SDOWN,且达到配置的 quorum

一旦 Master 进入 ODOWN,任意一个 Sentinel 都可以发起 Leader 选举。

2.2 选举的核心机制

3. 其他哨兵:陆续发现,表示赞同

Redis Sentinel 的 Leader 选举借鉴了 Raft 的思想,但实现更轻量。理解时可抓住以下几个概念:

过一会儿,S2、S3 也收不到主节点心跳,同样判定主节点主观下线。

2.3 选举过程时序

4. Leader 选出新主节点

复制代码
时间 ──────────────────────────────────────────────────────────────►
Leader 确定之后,从可用从节点里挑一个升主,规则按优先级依次比较:
  Master 被判定 ODOWN
         │
         ▼
  S1 发起选举(epoch = N)──────► 向 S2、S3 请求投票
         │
         │    S2 先收到 S1 的请求 ──► 投给 S1(本 epoch 已用掉一票)
         │    S3 后收到 S1 的请求 ──► 投给 S1
         │
         ▼
  S1 获得 2/3 票(过半)──► S1 成为 Leader,开始 Failover
         │
         │    (若 S2 也发起了选举但 S3 已投 S1,则 S2 无法过半,选举失败,等待下轮)
         ▼
  其他 Sentinel 进入「跟随 Leader 状态同步」模式,不再自行升主
顺序 规则 谁胜出
1 slave-priority 数值更小(优先级更高)
2 replication offset 数值更大(数据更新)
3 run id 字典序更小(打破平局)

选好后,Leader 执行切换,其余从节点改复制新主节点,Failover 完成。

相关推荐
太理摆烂哥3 小时前
MySQL表的操作
数据库
lbb 小魔仙3 小时前
时序数据库是什么?2026 年五款工业时序数据库横评与场景解析
数据库·时序数据库
零基础1233 小时前
权限管理怎么做?从“资格”与“空间”双维度设计一套可落地的权限体系
java·服务器·数据库
轮子大叔3 小时前
Redis深入浅出
redis·缓存
小小龙学IT3 小时前
PostgreSQL 服务端机制与 SQL 实战深度解析:从 MVCC 到查询优化器
数据库·sql·postgresql
l1t3 小时前
DeepSeek总结的DuckDB 从 JSON 字符串到类型化列
数据库·sql·json
Raas1004 小时前
AI网关能做调用审计吗?MAI Gateway(魔芋企业级AI网关)实战能力深度解读
java·服务器·网络·数据库·gateway·prompt·企业级产品
foolishlee4 小时前
openGauss同步提交
数据库
bksczm4 小时前
MySQL进阶篇之备份(下半篇)
数据库·mysql
计算机就业还在扩大4 小时前
Redis中的setnx是原子性的?
数据库·redis·缓存