• 阅读前提：了解 Redis 从单机部署 >> 主从部署 >> 哨兵部署 >> 集群部署演进的过程。

1 Sentinel 的 Leader 选举

• 这个选举发生在哨兵部署下，其目的是在多个 Sentinel 节点中选出一个领导者，由这个领导者来负责执行接下来的故障切换操作。这样可以避免多个 Sentinel 同时执行故障切换导致混乱；
• 触发条件：当一个Sentinel将主节点判定为客观下线（Objectively Down, ODOWN） 时，它就会发起选举；
• 选举过程（基于Raft算法）：
  1. 自增纪元（Epoch）：每次选举都会在一个新的纪元（Epoch） 中进行。这是一个全局的、不断递增的计数器（如1, 2, 3…）。每个纪元里，最多只能选出一个Leader；
  2. 拉票：
     • 发现主节点客观下线的 Sentinel 会向其他 Sentinel 节点发送一条命令，要求它们将自己选举为 Leader；
     • 这个拉票请求中会包含当前纪元的编号；
  3. 投票规则：
     • 每个 Sentinel 在一个纪元中只能投一票，且先到先得；
     • Sentinel 只会投票给第一个向自己发送拉票请求的节点；
     • Sentinel 不会投票给比自己当前纪元小的请求（防止旧的请求干扰）；
     • 只有已经将主节点标记为客观下线的 Sentinel 才会参与投票和拉票；
  4. 选举成功：
     • 如果一个 Sentinel 收到了超过半数（比如 3 个 Sentinel 中需要 2 票，5 个中需要 3 票）的同意票，那么它就成为了当前纪元的 Leader；
     • 如果投票失败（没有 Sentinel 获得多数票），Sentinel 会等待一段随机时间后，递增纪元号，发起新一轮选举。这个随机时间有助于避免多个 Sentinel 同时再次发起投票，提高选举效率。

2 从节点被 Leader “选举”

• 这个选举发生在 Sentinel Leader 已经被选出来之后（也是在哨兵部署下）。现在，这个 Leader Sentinel 需要决定将哪个从节点（Slave）提升为新的主节点（Master）；

• 触发条件：Sentinel Leader 已经被选举出来了，开始执行故障转移（Failover）流程；

• **选择规则（按优先级排序）：**Sentinel Leader 会按照以下规则对从节点进行筛选和排序：

  1. 优先级（slave-priority）：
     • 这是在 Redis 从节点配置文件中可以设置的一个参数（replica-priority 或 slave-priority）。数值越小，优先级越高；
     • Sentinel 会首先检查优先级。如果优先级不同，直接选择优先级最高（数值最小）的那个从节点。这是最直接的人为控制手段；
  2. 复制偏移量（Replication Offset）：
     • 如果多个从节点的优先级相同（默认都是100），Sentinel 会比较它们与旧主节点的复制偏移量；
     • 复制偏移量代表了从节点复制数据的完整程度。偏移量越大，说明从节点的数据越新；
     • 选择复制偏移量最大的那个从节点，以确保数据丢失最少；
  3. 运行ID（Run ID）：
     • 这是一个极端情况下的决胜规则。如果优先级和复制偏移量都完全一样，Sentinel 会比较每个从节点的运行ID。
     • 选择运行ID字典序最小的那个从节点。运行ID是 Redis 实例启动时随机生成的唯一标识符，这个规则相当于随机选择，但总能选出一个；

• 本节和1 Sentinel 的 Leader 选举是 Redis Sentinel（哨兵）部署场景下的故障转移流程，可以用下图来概括：

  

• 由此可见，此处的从节点“选举”并不是真正意义上的选举，这也是本节标题的“选举”两个字被打上引号的原因。而在集群部署下的 Redis，主节点宕机后，从节点才是真正地发起选举。

3 集群部署下从节点的选举

• 上面两节，讲述的是 Redis Sentinel（哨兵）部署场景下的故障转移流程；

• 实际上Redis 提供了两种主要的高可用方案，它们的故障转移机制完全不同：

  特性	Redis Sentinel（哨兵模式）	Redis Cluster（集群模式）
  核心目的	实现主从复制的高可用，管理的是主从架构	实现数据分片（Sharding） 和高可用，管理的是多分片多主多从的集群
  故障发现与决策者	由独立的 Sentinel 进程集群负责监控和决策	由集群中所有主节点（Master）共同负责监控和投票决策
  选举机制	两步选举： 1. 选举 Sentinel Leader；2. Sentinel Leader 根据规则选择一个从节点升主节点	一步选举： 从节点直接发起竞选，由所有主节点投票，超过半数同意则升主节点
  投票权	只在 Sentinel 节点之间	在所有主节点之间
  触发消息	Sentinel 之间使用 is-master-down-by-addr 等命令	从节点广播 FAILOVER_AUTH_REQUEST，主节点回复 FAILOVER_AUTH_ACK

• Redis Cluster（集群）的故障转移机制：

  • slave 发现 master 为 FAIL 状态：在 Redis Cluster 中，每个节点都会通过 Gossip 协议与其他节点通信。当一个主节点被大多数主节点认为不可达时，它会被标记为 FAIL 状态。它的从节点会检测到这一点；

  • 增加 currentEpoch 并广播 FAILOVER_AUTH_REQUEST：

    • currentEpoch 是集群级别的逻辑时钟，用于维护集群状态的一致性。从节点通过增加它来发起新一轮的选举周期；
    • FAILOVER_AUTH_REQUEST 是竞选消息，意思是“我想成为新的主节点，请投票给我”；

  • 只有 Master 响应并投票：

    • 在集群中，只有负责数据分片的主节点（Master）拥有投票权。它们会判断请求的合法性（例如，发请求的从节点是否属于已宕机的主节点，epoch 是否最新等）；
    • 每个主节点在一个给定的 epoch 内只能投一次票（先到先得），这样可以避免给多个从节点投票造成混乱；

  • 收集 FAILOVER_AUTH_ACK：发起竞选的从节点会等待接收各个主节点的投票（ACK）；

  • 获得超过半数投票则成为新 Master：

    • 这是分布式共识算法的核心（如Raft）。只有获得大多数（N/2 + 1）主节点的同意，从节点才能成功晋升。这确保了在同一时间最多只有一个从节点能成功升主；
    • 这也解释了为什么 Redis Cluster 至少需要 3 个主节点。如果只有 2 个主节点（A和B），当A宕机后，它的从节点需要获得 2/2 + 1 = 2 票才能当选。但此时集群只剩B一个主节点，最多只能拿到1票，无法满足多数票条件，因此故障转移会失败；

  • 新 Master 广播 Pong 消息：成功升主节点后，该节点会通过广播 Pong 消息（Gossip协议的一部分）通知集群中的所有其他节点更新配置信息，告知自己已经成为新的主节点，并负责原主节点的哈希槽（Hash Slots）。