Redis哨兵集群采用类Raft选举机制：主节点被quorum个哨兵确认客观下线（ODOWN）后，首个判定者抢占成为Candidate，经自荐广播、资格审核（最新epoch/未投票/确认ODOWN）、多数派胜出（≥quorum且＞半数）三阶段选出Leader，仅负责本次故障转移。
Redis 哨兵集群不直接运行标准 Raft 协议，而是借鉴其核心思想（如任期 epoch、Candidate 状态、多数派投票），实现一种轻量级的类 Raft 领导者选举机制。整个过程围绕“客观下线（ODOWN）”触发，严格依赖配置与状态协同，不是随时可发起的随意投票。
触发条件：必须先达成客观下线
选举不会在任意时刻启动，只有当主节点被判定为客观下线时才激活：
- 至少 quorum 个哨兵（由
sentinel monitor mymaster ip port quorum配置）各自独立认为主节点主观下线（SDOWN）； - 这些哨兵通过
SENTINEL is-master-down-by-addr命令互相确认，形成共识后将状态升级为 ODOWN； - 第一个完成 ODOWN 判定的哨兵立即成为 Candidate，开始拉票——它不等待、不协商，抢占式启动。
三阶段拉票：带任期和约束的投票流程
选举按固定节奏推进，每轮含超时控制，分三个明确步骤：
-
自荐与广播：Candidate 向所有其他哨兵发送
is-master-down-by-addr请求，携带自身 runid 和当前current_epoch（每次选举递增），并给自己投一票； - 投票资格审核：其他哨兵只在同时满足三项条件时才投赞成票：收到的 epoch 是最新值、自己本轮尚未投过其他 Candidate、且本地也确认主节点处于 ODOWN 状态；
- 胜出判定：Candidate 收到的赞成票数必须同时满足两个门槛——≥ quorum，且 > 总哨兵数的一半（即多数派）。例如 5 个哨兵时需至少 3 票，哪怕 quorum 配的是 2。
失败与重试：无永久阻塞设计
若一轮未达成胜出条件，Candidate 会重置状态，等待选举超时（默认 45 秒）后开启新任期、新 epoch，重新发起拉票。期间其他哨兵若发现更早的 epoch 已失效，也会拒绝旧请求，确保选举始终向前推进。
当选后的职责：仅负责故障转移协调
Leader 并不长期掌权，它的唯一使命是主导本次故障转移：从所有从节点中选出新主（依据复制偏移量、优先级、runid 等）、下发 SLAVEOF 指令、更新配置纪元（config_epoch）、通知客户端。一旦转移完成，该 Leader 职责即结束，下次 ODOWN 仍需重新选举。
