主节点宕机从节点晋升

机制概述

当 Redis 主节点发生宕机时，系统需要从它的从节点中选出一个来接替主节点角色，继续提供写入服务。这个”从节点晋升”过程在哨兵架构和 Cluster 架构中的实现有所不同，但核心逻辑相似。

哨兵架构中的从节点晋升

完整流程

1. 主节点宕机
2. 哨兵检测到主节点 ODOWN（客观下线）
3. 哨兵集群选举领导者哨兵
4. 领导者哨兵选择新主节点 ← 这是从节点晋升的关键
5. 晋升操作：对选中从节点发送 SLAVEOF NO ONE
6. 重新配置其他从节点复制新主节点
7. 通知客户端
8. 旧主节点上线后降级为从节点

从节点选择标准（哨兵版）

哨兵 leader 在选择晋升哪个从节点时，按以下优先级筛选：

1. 剔除不可用的：排除 SDOWN、断连时间过长的从节点
2. 按 replica-priority 排序：值越小越优先（priority=0 的永不晋升）
3. 按复制偏移量排序：偏移量越大表示数据越新，越优先
4. 按 run_id 排序：run_id 字典序最小的优先

晋升操作

SENTINEL failover 
// 或直接对从节点执行：
SLAVEOF NO ONE

执行后：
– 从节点停止复制，成为新的主节点
– 开始接受写入
– config epoch 递增

Cluster 架构中的从节点晋升

完整流程

1. 其他主节点通过 Gossip 检测到主节点 PFAIL → FAIL
2. 从节点检测到主节点 FAIL
3. 从节点计算延迟时间（避免多个从节点同时发起选举）
4. 延迟时间最短的从节点发起投票请求
5. 其他主节点投票（需获得半数以上支持）
6. 获选从节点晋升为新主节点
7. 广播槽位信息变更
8. 其他从节点开始复制新主节点

延迟时间计算

为了减少多个从节点同时竞选造成的冲突，Cluster 中的从节点会计算一个随机延迟：

延迟时间 = (节点排名 × 1000ms) + random(0, 500ms)

其中”节点排名”是根据 replica-priority 和复制偏移量计算得到的。排名越靠前（数据越新、优先级越高），延迟时间越短，越早发起选举。

投票机制

• 从节点向所有主节点发送投票请求
• 每个纪元（epoch）内，主节点最多只能给一个从节点投票
• 获得半数以上主节点投票的从节点才能晋升
• 如果选举失败（未获得足够票数），等待下一个纪元再次发起

晋升后的数据一致性

可能的丢失

从节点晋升为新的主节点后，原主节点上已写入但尚未同步到从节点的数据会丢失。这就是 Redis 异步复制的固有缺陷。

丢失量估算

最大丢失量 ≈ 从节点延迟时间（秒）× 写入 QPS

例如：延迟 1 秒，写入 QPS 为 5000，最多丢失 5000 个 Key。

减少丢失的方法

1. 配置 min-replicas-to-write 和 min-replicas-max-lag：至少保证一个从节点同步最新数据
2. 使用 WAIT 命令：在主节点写入时等待至少 N 个从节点确认
3. 缩短主从延迟：优化网络、避免大 Key 同步

从节点晋升后的架构变化

角色变更

晋升前：                     晋升后：
主节点 A                     新主节点 B（原从节点 B 晋升）
从节点 B（将被晋升）         从节点 A（原主节点，上线后降级）
从节点 C                     从节点 C（切换到复制新主节点 B）

配置纪元（config epoch）

晋升时，新主节点的 config epoch 会递增，且新值会大于集群中所有其他节点的 epoch。这在冲突解决时非常重要——epoch 最大的节点拥有最高权威。

特殊场景

场景一：所有从节点都不可用

如果主节点宕机时，所有从节点也都不可用（或者全部 replica-priority=0），那么：

• 哨兵架构：无法完成故障转移，服务不可用
• Cluster 架构：该主节点的槽位无法提供服务，处于”失联”状态

场景二：从节点数据严重过期

如果从节点与原主节点的数据差距过大（超过 cluster-replica-validity-factor × cluster-node-timeout），集群会阻止该从节点晋升，因为它无法代表最新数据。

场景三：并行晋升

在一个主节点有多个从节点的情况下，如果第一个从节点晋升失败（未获得足够票数），其他从节点会依次尝试。但每个纪元只有一”轮”选举。

面试要点

• 晋升流程：检测故障 → 筛选从节点 → 选举 → 切换角色 → 重新配置
• 关键指标：replica-priority 决定优先级，复制偏移量决定数据完整性
• 数据丢失：异步复制的固有弱点，可用 WAIT 或 min-replicas-to-write 缓解
• 冲突解决：epoch（配置纪元）决定权威性

总结

主节点宕机后的从节点晋升是 Redis 高可用架构的核心功能。哨兵和 Cluster 虽然实现细节不同（哨兵依赖外部哨兵集群决策，Cluster 依赖节点间的分布式共识），但核心逻辑一致：从符合条件的从节点中，选择数据最新、优先级最高的一个，通过多数派确认后完成角色切换。这个过程的快慢直接影响 Redis 的故障恢复时间（RTO）。