Redis Sentinel 选举机制详解（Master选举+Leader选举）

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花

Sentinel 是 Redis 高可用架构的核心组件，内置两套独立且联动的选举机制：Leader 选举（Sentinel 集群内部决策节点选举）和Master 选举（故障后主节点选举）。两者分工明确：Leader 选举解决“谁来执行故障转移”，避免集群并发操作混乱；Master 选举解决“选哪个 Slave 当新主”，保证数据完整性和集群可用性。

一、Sentinel Leader 选举机制（集群决策者选举）

1. 核心定位与触发时机

Leader 选举是 Sentinel 集群内部的分布式共识选举，基于类 Raft 算法实现，仅当 Master 被判定为客观下线（ODown）时触发。目标是选出唯一的 Sentinel Leader，由其全权执行后续故障转移、新主推送、从节点重配置等操作，杜绝多 Sentinel 同时操作导致的脑裂问题。

2. 完整选举流程

1. 发起竞选：首个判定 Master 客观下线的 Sentinel，自动成为候选者，生成当前故障转移的epoch（任期/纪元），向集群内其他 Sentinel 发送投票请求，申请成为 Leader。
2. 投票规则：每个 Sentinel 在同一 epoch 内只能投一票，遵循“先到先得”原则；未投票的 Sentinel 收到请求后，若认可候选者的客观下线判定，直接投赞成票。
3. Leader 胜出条件：候选者获得超过半数 Sentinel 节点的选票（公式：floor(N/2)+1，N 为在线 Sentinel 总数），立即成为 Leader，独占故障转移权限。
4. 选举超时与重试：若首轮选举无节点达标，会触发新一轮 epoch 重新竞选，直至选出 Leader；选举过程快速高效，通常毫秒级完成。

3. 关键特性

• 一纪元一票：同一故障转移任务（同一 epoch）内，投票不可逆，杜绝重复投票。
• 多数票原则：必须获得集群半数以上认可，保证决策权威性，避免分区决策。
• 先到优先：最早发现客观下线、最早发起投票的 Sentinel，胜出概率极高。

Leader 是临时角色，仅负责当前故障转移任务；下次 Master 故障时，会重新选举新 Leader，无固定 Leader 节点。

二、Sentinel Master 选举机制（新主节点选举）

1. 核心定位与前置条件

Master 选举由 Sentinel Leader 执行，仅在 Leader 当选后启动，核心是从存活 Slave 中筛选最优节点升级为新 Master，筛选逻辑严格遵循“优先级+数据完整性+唯一性”原则，最大限度减少数据丢失。

前置筛选：先剔除不合格 Slave 节点主观下线、与 Master 断开过久（超过 down-after-milliseconds 10 倍）的节点复制异常、无有效同步数据的节点手动标记为不可参与选举的节点

2. 多层级选举排序规则（优先级从高到低）

第一层：Slave 优先级（slave-priority）

这是人工可干预的核心指标，配置值越小优先级越高（默认 100）。运维可通过调整该参数，指定硬件更好、位置更优的节点优先成为 Master。若存在优先级更低的节点，直接跳过更高优先级节点，进入下一层筛选。

第二层：复制偏移量（replication_offset）

优先级相同时，对比 Slave 与原 Master 的复制偏移量，偏移量越大表示数据越新，优先当选。偏移量是 Redis 复制的核心标识，代表 Slave 已同步的字节数，最大限度保证故障转移后数据丢失最少。

第三层：节点运行 ID（runid）

若优先级和偏移量完全一致，对比 Slave 的唯一运行 ID，runid 字典序更小的节点胜出。这是兜底规则，保证选举结果唯一，无平局情况。

3. 新主确认与集群重构

1. Leader 选中最优 Slave 后，发送 SLAVEOF NO ONE 命令，将其升级为独立 Master。
2. 向其余 Slave 推送新主地址，执行 SLAVEOF 命令同步新 Master 数据。
3. 更新集群配置，标记旧 Master 为下线状态；若旧 Master 恢复，自动降级为 Slave 同步新主。

三、两大选举机制核心对比

Sentinel 集群建议部署奇数个节点（3/5/7），既满足 Leader 选举的多数票原则，又能避免脑裂，提升高可用稳定性。

ps：如果这篇帖子对于还在找工作和找实习的你有所帮助，可以关注我，给本贴点赞、评论、收藏并订阅专栏；同时不要吝啬您的花花