第 298 题：实现一致性协议Raft，Leader选举与日志复制。
题目
实现一致性协议Raft，Leader选举与日志复制。
完整讲解
一、Raft 简述
- Raft：一种一致性协议，使多副本在部分节点故障、网络分区下仍就「同一份日志」达成一致，用于复制状态机。核心包括Leader 选举与日志复制两大部分。
二、Leader 选举
- 角色：Leader（处理写、复制日志）、Follower（被动接收）、Candidate（参与选举）。任期（term）递增。
- 触发：Follower 在选举超时内未收到 Leader 心跳则转为 Candidate，term+1，向其他节点请求投票；若获多数票则成为新 Leader，向所有节点发心跳。
- 投票规则：每个节点每 term 最多投一票；通常投给「日志至少不比自己旧」的 Candidate（比较 lastLogIndex、lastLogTerm），保证已提交的日志不会被覆盖。
- 分裂与重选：若无人获多数，超时后重新选举；随机化超时减少同时竞选。
三、日志复制
- 流程：Client 写请求到 Leader；Leader 将条目追加到本地日志，并并行复制到多数 Follower；Follower 持久化后回复；Leader 收到多数 ack 后提交该条目并应用状态机，再回复 Client。
- 一致性：Leader 不删除或覆盖自己的日志；若某条在某一 term 被某 Leader 提交，则更大 term 的 Leader 一定包含该条（由选举的「日志不更旧」保证）。Follower 与 Leader 冲突的日志可被 Leader 的后续条目覆盖（通过 nextIndex 与一致性检查）。
- 实现要点：持久化 currentTerm、votedFor、log[]；选举与复制时的 RPC；安全性与 liveness 的证明依赖「选举约束」与「提交规则」。
面试要点
- 能说清 Raft 的两种核心机制：Leader 选举（超时、投票、多数、日志不更旧）与日志复制（Leader 追加、复制多数、提交）。
- 能说明投票规则为何能保证已提交日志不丢；能简述冲突时 Leader 如何覆盖 Follower 日志（nextIndex 回退）。
记忆要点
- Raft：Leader 选举（超时→Candidate→请求投票→多数成 Leader）；日志复制（Leader 追加→复制多数→提交）。
- 投票投给日志不更旧的；已提交的日志不会被覆盖；冲突时 Leader 用 nextIndex 覆盖 Follower。