共识算法的 Leader 选举是怎么保证选出唯一 Leader、避免脑裂的？
简化版
共识算法通常通过任期编号、多数派投票和心跳机制来选 Leader。候选人必须获得超过半数节点投票才能成为 Leader；每个节点在同一任期只投一票，所以同一任期不可能有两个候选人同时获得多数。任期号用于淘汰旧 Leader，心跳用于维持领导权。网络分区时，只有多数派分区能选出有效 Leader，少数派即使有旧 Leader，也无法提交写入。
详细版
Leader 选举的核心不是“谁先发请求谁赢”，而是“谁能拿到多数派授权”。多数派有交集，每个节点同一任期只投一票，因此两个不同候选人不可能在同一任期都获得多数票。
为了避免旧 Leader 继续工作，协议会给选举引入任期、epoch 或 zxid 这类单调递增编号。节点看到更大的任期，会承认新任期并放弃旧身份。旧 Leader 在网络分区中可能还认为自己是 Leader，但它无法联系多数派，因此不能提交新写入。
工程上还要处理随机选举超时、租约、时钟偏差、读请求一致性和成员变更。避免脑裂的关键是：写入必须经过多数派确认，不能只依赖本地 Leader 身份。
完整版教学
一、Leader 选举为什么是共识系统的核心
很多分布式系统会设置 Leader，因为所有写请求走一个入口，日志顺序更容易统一。但 Leader 本身会带来一个危险：如果两个节点都以为自己是 Leader，就可能各自接受写入，形成脑裂。脑裂最可怕的不是“状态短暂不一致”，而是两个分区都对外承诺成功，之后很难无损合并。
因此 Leader 选举真正要保证的是“有效 Leader 唯一”。注意这里说的是有效 Leader，而不是所有节点主观上都立刻知道唯一。网络分区下，旧 Leader 可能短时间不知道自己已经失效，但只要它无法获得多数派确认，就不能完成安全写入。
二、多数派投票如何保证唯一性
选举通常要求候选人拿到超过半数投票。以 5 节点为例，多数是 3 票。任意两个 3 票集合必然至少有一个共同节点。如果每个节点在同一任期只能投一票，那么同一任期内两个候选人不可能同时拿到 3 票。
这个交集性质是避免双 Leader 的根基。不是因为节点“很听话”就不会脑裂，而是数学上两个多数派无法完全分离。只要协议规定 Leader 必须来自多数授权，同一任期就只能产生一个有效 Leader。
三、任期编号如何淘汰旧 Leader
只靠投票还不够，因为系统会有旧消息、延迟消息、网络恢复后的历史消息。共识协议通常会引入 term、epoch、ballot、zxid epoch 等单调编号。每次选举进入新编号，所有投票、心跳、日志复制请求都携带这个编号。
节点收到更大的编号，就更新本地编号并承认新任期；如果自己曾经是 Leader，也要退回 Follower。节点收到更小编号的请求，则拒绝。这样旧 Leader 即使还在发送心跳或写请求，也会被新任期节点拒绝，无法继续扩大影响。
四、网络分区时如何避免脑裂
假设 5 节点集群被切成 2 个和 3 个两个分区。3 节点分区可以凑出多数，能够选出新 Leader 并提交写入；2 节点分区凑不出多数，即使里面有旧 Leader，也不能安全提交。这样系统牺牲少数派可用性，保住整体一致性。
这也是 CP 系统在分区下的典型选择：多数派继续服务，少数派拒绝写入或降级为只读。面试时要把“Leader 还活着”和“Leader 有多数派授权”区分开。活着不代表有效，有效必须能拿到多数派。
五、选举活性如何保证
唯一性解决安全问题，活性解决能不能尽快选出 Leader。Raft 用随机选举超时降低同时竞选概率；ZooKeeper 的 ZAB 会基于 zxid 和 server id 做 Leader 选举；Paxos 系实现也会通过稳定 Leader 或租约减少冲突。
如果多个候选人同时发起选举，可能出现选票瓜分，没有人获得多数。协议通常会让节点等待随机时间后进入下一轮任期重新选举。只要网络恢复、超时参数合理，最终会有一个候选人先拿到多数，系统重新进入稳定状态。
六、面试追问与工程边界
常见追问是“有了 Leader 选举，读请求是不是一定安全”。答案是否定的。旧 Leader 在少数派里可能还没意识到自己失效，如果它直接本地读，可能返回过期数据。线性一致读通常需要 Leader 与多数派确认，例如读前心跳确认、ReadIndex、租约读或提交 no-op。
另一个追问是租约能否代替多数派。租约可以优化读路径，但依赖时钟假设和网络时延边界，必须非常谨慎。写入路径通常仍要多数确认。把 Leader 身份、写入提交、强一致读这三件事分开讲，答案会更扎实。
七、常见误区与追问
这道题不能只背概念，要把「Leader 选举」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | Leader 选举通过任期、投票和多数派让集群在同一时刻最多承认一个合法 Leader | 不要停在名词解释 |
| 流程机制 | Follower 选举超时 -> 递增 term 转 Candidate -> 向其他节点请求投票 -> 获得多数派成为 Leader -> 定期发送心跳维持领导权 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | 5 节点集群候选人至少获得 3 票才能成为 Leader，两个候选人不可能同时拿到两个不相交多数派 | 一致性协议用延迟和可用性换确定顺序，不能只背 Paxos/Raft 名词 |
Leader 选举 面试拆解：
1. Follower 选举超时
2. 递增 term 转 Candidate
3. 向其他节点请求投票
4. 获得多数派成为 Leader
5. 定期发送心跳维持领导权记忆钩子：先说明故障模型和多数派，再拆选主、日志复制、提交、恢复和安全性边界；回答时要紧扣「Leader 选举」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：谁先超时谁一定成为 Leader。 还要看是否获得多数派投票，以及日志是否足够新。
- 误区：心跳只是健康检查。 心跳也用于维持 Leader 权威并阻止其他节点发起选举。
- 误区：偶数节点更省机器也一样好。 多数派容错下偶数节点通常不提升可容忍故障数，还增加投票复杂度。
- 追问：随机选举超时有什么用？ 降低多个节点同时发起选举导致平票的概率。
- 追问：脑裂怎么避免？ 多数派投票和任期规则保证只有多数派一侧能产生合法 Leader。
- 追问：Leader 故障多久恢复？ 取决于心跳间隔和选举超时配置，通常是毫秒到秒级。
八、加强记忆
Leader 选举避免脑裂靠三件事：多数派授权、单任期单票、任期编号。多数派保证两个 Leader 不可能在同一任期都拿到授权；任期编号淘汰旧 Leader；写入必须多数确认，少数派旧 Leader 不能提交。面试别只说“心跳检测”，心跳只是发现故障，真正保证唯一有效 Leader 的是 Quorum 和任期规则。