Raft
Raft 是可理解的共识协议：把 Paxos 的复杂性拆成三个子问题。面试必考：选举、复制、安全性。
三个子问题
| 子问题 | 解决 |
|---|---|
| Leader 选举 | 谁当领导 |
| 日志复制 | 怎么保持一致 |
| 安全性 | 怎么保证不丢已提交日志 |
角色与任期
- 三种角色：Leader（领导）、Follower（跟随）、Candidate（候选）
- 任期（term）：单调递增的编号，每次选举 +1
- 心跳：Leader 定期发心跳，Follower 超时未收到 → 变 Candidate 发起选举
Leader 选举
选举: 超时触发, 多数票当选
- 选举超时是随机的（150-300ms），避免同时竞选（分裂投票）
- 得票过半当选（多数派原则）
- 任期分裂：选不出时超时重选（随机超时保证最终收敛）
日志复制
1. 客户端请求 → Leader 追加日志条目
2. Leader 并行发 AppendEntries 给所有 Follower
3. 多数派确认后: 条目"已提交", Leader 应用到状态机
4. 下一心跳携带提交索引, Follower 应用- 多数派确认才提交：少数派故障不影响（过半即可）
- 已提交的日志不会被覆盖（安全性保证）
- 读也要经过 Leader 或 ReadIndex（保证线性一致，见一致性模型篇）
安全性：日志匹配与选举限制
| 机制 | 保证 |
|---|---|
| 日志匹配 | 同索引同任期 = 同内容（AppendEntries 一致性检查） |
| 选举限制 | 候选人日志必须“足够新”才能当选（投票前比较） |
| 提交规则 | 只提交当前任期的条目（防旧 Leader 覆盖新日志） |
这些规则保证：已提交的日志永不会丢（这是 Raft 的核心安全性）。
应用
| 系统 | 用途 |
|---|---|
| etcd | 分布式 KV（K8s 元数据存储） |
| Consul | 服务发现、配置 |
| Kafka KRaft | 元数据管理（见 Kafka 架构篇） |
| TiKV | 分布式存储 |
面试话术：Raft 是“多数派 + 任期 + 日志”的组合。etcd 是它的最佳实践样本（K8s 的存储底座）。
面试追问
- Raft 三个子问题？ 选举、日志复制、安全性。分解 Paxos 的复杂性
- 怎么选 leader？ 心跳超时 → Candidate → 随机超时防分裂 → 多数票当选
- 日志怎么提交？ Leader 复制到多数派才提交。少数派故障不影响
- 为什么不丢已提交日志？ 选举限制（日志新的才能当选）+ 提交规则（当前任期）。安全性核心
- Raft 用在哪？ etcd（K8s）、Consul、KRaft。配置/元数据类强一致场景