🚀 Raft 共识算法
导语： Raft 是后端面试的高频考点，工业界大名鼎鼎的 etcd、Consul、TiKV 都基于它实现。Raft 把复杂的共识问题巧妙拆成了三大模块：Leader 选举、日志复制、安全性。今天带你快速搞定它！
❓ 什么是 Raft
Raft 的诞生是为了解决 Paxos 难以理解、难于工程实现的问题。它以“可理解性”为核心目标，将共识拆分为三个独立的子问题：🔹 Leader 选举🔹 日志复制🔹 安全性约束
🎭 三种节点角色
-
👑 Leader：处理客户端写请求，持续发送心跳。
-
🙋♂️ Follower：被动响应，不主动发起请求。
-
🗳️ Candidate：选举时的临时角色，用于竞选 Leader。
⏳ 核心概念：Term（任期）
单调递增的数字，每发起一次选举 Term +1，用来识别过期 Leader。
⚙️ 核心机制一：Leader 选举
-
超时触发
Follower 长时间收不到 Leader 心跳 → 转为 Candidate，Term +1，给自己投一票。
-
拉票请求
**
Candidate 向其他节点发起投票请求。
**
-
胜出条件
**
拿到多数派选票，成功成为 Leader。
**
💡 核心设计：随机超时偶数节点容易平票；Raft 依靠随机选举超时 (150ms‑300ms)，错开竞选时间，重新选举，避免集体同时竞选。
📝 核心机制二：日志复制
客户端写完整流程：
-
Leader 将日志追加到本地。
-
通过
AppendEntries RPC，并行推送给所有 Follower。 -
多数派复制成功，Leader 执行 commit，返回客户端写成功。
-
后续心跳通知 Follower 提交日志。
🔗 日志匹配特性
-
如果两个日志在相同 index、相同 term 的记录一致，则这条记录之前的全部日志都完全一致。
-
日志冲突时，Leader 强制 Follower 同步覆盖自己的日志。
🛡️ 3. 安全性约束
安全性约束是保证 Raft 集群状态机正确的前提：
| 约束 | 说明 | | --- | --- | | 选举限制 | Candidate 日志必须比集群大多数节点“更新”，否则不能当选 Leader | | 提交规则 | Leader 只能提交当前 term 的日志，不能直接提交旧任期日志 | | 日志匹配 | Leader 强制 Follower 对齐日志，保证集群日志一致 |
⚔️ Raft vs Multi‑Paxos（面试常考对比）
| 对比项 | Raft | Multi‑Paxos | | --- | --- | --- | | 理解难度 | 低，易上手 | 逻辑复杂，难实现 | | Leader 选举 | 独立显式流程 | 选举逻辑隐式内嵌协议 | | 日志流向 | Leader 单向推送给 Follower | 支持双向交互 | | 成员变更 | 联合共识，简单 | 实现复杂 | | 落地实现 | etcd/Consul/TiKV，开源多 | 大多厂商自研 |
💡 一句话总结
Raft 是强一致性 CP 协议，通过选主 + 日志复制保证集群数据一致；依靠随机超时解决选举冲突；Leader 只能提交当前任期日志是 Raft 非常关键的安全点；相比 Paxos，牺牲一部分理论极致，换取好理解、好实现。
