6.2 Raft 可读的强化 Paxos

6.2 Raft：把 Paxos 装进选举、任期与日志复制

Raft 是站在 Paxos 肩膀上、专门为"可读、可工程化、可维护"而生的共识算法。它把一致性的达成拆成三件独立的机械——选主、任期推进、日志复制——并坚持"一个时刻只有一个 leader 说了算"。本节顺着这三件套走一遍，重点讲 leader 任期如何让一切变简单、以及一条日志从写入到被多数确认再到提交的时间线。

学习目标

阅读完本节，你应当能够：

1. 说出 Raft 的三个核心机制及其分工。
2. 描述一个 leader 的任期如何开始、如何获得确认、如何推进日志。
3. 说明 leader 宕机后 Raft 靠什么快速选出新主、而日志又怎么以免丢。

Raft 为什么能赢过"正统"

Paxos 理论上是共识的圣杯，可工程界吃它的苦头不少：理解成本高、实现容易错、出 bug 不好查。Raft 的诞生立场很朴素——"把 Paxos 讲明白"。它不是推翻，而是把共识拆成三块各管一摊的机制，并且坚持**"着一个 leader 管事"**这个唯一真旨。因为"有一个明确的 leader"比"大家平等地提案"好理解得多，也自然解决了"日志顺序由谁定"的难题。几乎所有用共识做日志复制的现代系统，最终都倒向 Raft（TiKV、etcd、CockroachDB 的前端协调即是）。

一、三件套：选主、任期、日志复制

选主：节点要么当 leader、要么当 follower（还有短暂竞选态）。follower 一旦了很久没收到 leader 心跳，就发起新一轮选举，给自己投票、请求别人投它，得多数票者当新 leader。

任期：每一次选举产生一个新"任期"，任期号单调递增。这个任期号是 Raft 的"身份证"——旧的任期意见永远拗不过新的任期，于是"谁先谁后"算法上就清楚了。

日志复制：leader 收下客户端的写请求后，把它记成一条日志，广播给所有 follower；当期多数 follower 确认"收到并写进本地日志"后，leader 才把这条日志标记为"已提交"并应用。全程只有 leader 能推进提交，这就回避了 Paxos 里那个众所周知的"多提案者互相博弈"。

Raft 的三种角色与切换

二、一条日志的完整旅程

用一个具体场景串起来：客户端给 leader 发了"把键 K 的值写成 V"。过程大致是：

1 leader 收下请求,为之分配,将它作为一条新日志追加到自己的日志尾
2 leader 把这条日志连同任期广播给所有 follower
3 每个 follower 把日志落进本地、回 ACK 给 leader
4 leader 等到多数(含自己)确认,把这条日志标记为已提交
5 leader 返回客户端"已写入",并把提交信息下发给所有 follower 应用
​

注意第 4 步是"多数确认"而不是"全部确认"——这正是 Raft 能在一个节点暂时宕掉时照样前进的原因。宕掉的那台回来后再补拉日志，不丢不重。

三、任期：把时间切成一段段，谁先谁后就有据可查

Raft 能把复杂收敛到"跟着 leader 走"，全靠任期这个巧思。它把整个运行时间切成一段段的"任期"，每一次选举诞生一个新任期，任期号单调递增。所有节点在竞标 leader 时都要带上当前的任期号，任期越大，话语权越大——一个旧任期的 leader 一旦发现更大任期存在，立刻让位。这给"谁先生效、谁说了算"提供了一个绝对判据，也自然地阻止了"两个势均力敌的 leader 同时号令一方"的脑裂。

连续的任期推进

下面这张 SVG 用一条时间轴展示多个任期如何被选主隔开、以及日志如何在任期之间延续：

Raft 的任期推进与日志延续

四、leader 挂了怎么办：快速换腰

最关键的容灾场景是 leader 失联。此时所有 follower 的心拍卖过期限，各自发起选举（先超时的先举手）；跑得最快的那个能拿到多数票、当选新 leader。这里要小心一个细节：新 leader 的日志不一定会部跟旧 leader 一模一样长——协议强制"日志短或被淘汰的节点不能阻挠最新日志的提交"，通过让节点在提交前对齐到 leader 日志的最新位置，保证数据不会因为换主而丢或乱。所以 Raft 的容灾不是靠某个天才节点，而是靠"多数确认 + 任期排位"这套机制自然兜住的。

五、Raft 最容易被看走眼的三处

Raft 号称"好读"，但真上手仍有三处最易误会，提前给你排雷：

一，"多数确认才提交"不等于"全部确认"。 老想着"等所有 follower 都写了才敢提交"，那就又滑回性能最差的路。Raft 只需多数确认即可提交、并返回客户端成功；少数落后的节点稍后补拉日志即可，不丢不重。

二，任期大就一定是权威吗。 更准确说是"任期号越大、越接近当前世界线"。一个旧任期 leader 发现更大任期存在就会主动让位；但"任期大"本身不保证它日志最全，核心还是靠"新 leader 强制让其他人对齐到它的日志"。

三，选举不是越频繁越安全。 心跳超时配得过短，正常抖动也会频繁触发选主、引发无谓的任期翻涌和短暂的不可用。把超时设成一个"略大于正常网络抖动"的值，比把选举调得很快更有助于稳定——这跟"活细水长流"一个道理。

把这三处捋顺，你在读任何 Raft 实现的代码时，就不会被"看起来像少了点什么"绊住。

本节要点回顾

• 三件套：选举产生 leader、任期排先后、日志走走多数确认。
• 唯一 leader：只让 leader 推进提交，化解 Paxos 的多提案博弈。
• 多数确认：多数点头即可提交，容忍部分节点宕机。
• 换主不丢：任期排位 + 强制对齐，数据不乱不丢。

Raft 解决了"听谁的"，但"要听多数"再说细一点，就落到"这个多数到底要几票"——这正好是下一节 Quorum 的专场：N、W、R 怎么配、那条 W+R>N 的铁律又为什么成立。