彻底搞懂 Raft 算法：为“被理解”而生的分布式共识

在分布式系统的世界里，共识（Consensus）是一个核心难题：如何让一堆机器对某个值（比如数据记录）达成一致？

很久以来，Paxos 算法是这个领域的“神”，但它太难懂了，难懂到连工程师都难以正确实现它。于是，Raft 诞生了。Raft 的设计初衷非常直白——“为了被理解”。它将复杂的共识问题拆解得清晰明了。

要理解 Raft，其实只需要搞懂三个核心问题：

老大是怎么选出来的？（Leader Election）
数据是怎么同步的？（Log Replication）
出了问题怎么办？（Safety & Network Partition）

本文将通过图解的方式，带你拆解 Raft 的核心原理。

一、核心概念：三个角色与任期

在 Raft 集群中，任何时候，一个节点只能处于以下三种状态之一。我们可以把它想象成一个由群众、竞选者和独裁者组成的微型社会。

1. 三种角色 (Roles)

Leader（领导者/独裁者）：
- 特权：全权负责处理客户端的写请求，把日志复制给 Follower。
- 义务：它必须不断给 Follower 发心跳（Heartbeat），证明自己还活着，否则会被“罢免”。
Follower（追随者/群众）：
- 本分：平时不说话，只响应 Leader 的指令（写数据）和 Candidate 的拉票请求。
- 造反：如果在一段时间内没收到 Leader 的心跳，它就会认为 Leader 挂了，从而变身 Candidate。
Candidate（候选人/竞选者）：
- 目的：当 Follower 没听到 Leader 的声音，就会变成 Candidate，发起投票，试图成为新 Leader。

2. 任期 (Term)

Raft 将时间划分为一个个的 Term（任期），用递增的数字表示（Term 1, Term 2...）。

每一届任期开始都是一次选举。
规则：如果一个节点发现别人的 Term 比自己大，它会立马变回 Follower（认怂）。这就像前朝皇帝遇到了新朝皇帝。

角色状态转换图

stateDiagram-v2[*] --> FollowerFollower --> Candidate : 选举超时 (收不到心跳)Candidate --> Leader : 获得大多数选票Candidate --> Follower : 发现更高任期 / 输掉选举Candidate --> Candidate : 选举超时 (平票，重新选举)Leader --> Follower : 发现更高任期 (比如网络恢复后)

二、阶段一：Leader 选举 (Leader Election)

Raft 使用心跳机制来触发选举。只要 Leader 还在发心跳，Follower 就乖乖听话；心跳一停，天下大乱。

1. 触发选举

Follower 节点有一个选举超时定时器（Election Timeout）（通常在 150ms-300ms 之间随机）。

正常情况：收到 Leader 心跳 -> 重置定时器 -> 继续当 Follower。
异常情况：定时器倒计时结束（超时） -> 变身 Candidate。

2. 竞选流程

当一个节点变成 Candidate 后，它会执行以下动作：

任期 +1（Term ++）。
给自己投一票。
群发 RequestVote RPC：向所有其他人喊话“请投我一票！”。

3. 谁能当选？

其他节点收到拉票请求，会根据以下原则投票：

先来后到：一个任期内，票只有一张，先给谁就是谁的。
比我新：你的日志不能比我的旧。

结果判定：

赢了：获得了集群大多数（N/2 + 1）的票数 -> 成为 Leader -> 立即发送心跳宣告主权。
输了：收到了别人的心跳（说明别人赢了） -> 变回 Follower。
僵局（Split Vote）：票数对半开，谁都没过半。

4. 巧妙的“随机超时”

为了解决僵局，Raft 让每个节点的超时时间是一个随机值。这保证了大概率有一个节点会“先醒来”并发起投票，从而打破平衡。

选举流程图

sequenceDiagramparticipant A as Node A (Follower)participant B as Node B (Follower)participant C as Node C (Leader - 已挂)Note over C: Leader C 宕机Note over A: 等待心跳... 超时!Note over A: 状态变为 Candidate<br/>Term = Term + 1<br/>给自己投一票A->>B: RequestVote (请投我!)Note over B: 还没投过票<br/>日志也并不比A新B-->>A: VoteGranted (同意!)Note over A: 拿到 2 票 (总共3节点)<br/>满足大多数!Note over A: 状态变为 LeaderA->>B: Heartbeat (我是老大了)

三、阶段二：日志复制 (Log Replication)

Leader 选出来了，现在开始干活。Raft 保证数据的强一致性。

流程步骤

Client 请求：客户端发送命令 set x=5 给 Leader。
预写入 (Append)：Leader 把命令写入本地日志（状态：Uncommitted），并并行发送 AppendEntries RPC 给 Follower。
Follower 写入：Follower 收到日志，检查一致性。如果没问题，写入本地日志，返回 Success。
提交 (Commit)：
- Leader 收到大多数 Follower 的 Success。
- Leader 将日志标记为 Committed，应用到状态机（执行 x=5）。
- Leader 给客户端返回“成功”。
后续同步：Leader 在下一次心跳中告诉 Follower：“刚才那条已提交，你们也可以应用了。”

日志复制流程图

sequenceDiagramparticipant Clientparticipant Leaderparticipant Follower1participant Follower2Client->>Leader: set x=5Note over Leader: 1. 写入本地日志 (Uncommitted)par 并行发送Leader->>Follower1: AppendEntries (x=5)Leader->>Follower2: AppendEntries (x=5)endNote over Follower1: 2. 写入本地日志Follower1-->>Leader: SuccessNote over Follower2: 2. 写入本地日志Follower2-->>Leader: SuccessNote over Leader: 3. 收到大多数响应 (2/3)Note over Leader: 4. Commit 并应用状态机Leader-->>Client: 返回成功 OKpar 通知提交Leader->>Follower1: 下次心跳: "x=5 已提交"Leader->>Follower2: 下次心跳: "x=5 已提交"endNote over Follower1: Commit 并应用Note over Follower2: Commit 并应用

四、阶段三：安全性与脑裂 (Brain Split)

分布式系统最怕网络分区（Network Partition）。假设 5 个节点（A, B, C, D, E）裂变成了两半：[A, B] 和 [C, D, E]。

场景演练

旧 Leader (A) 的困境：
- A 在 [A, B] 分区。Client 给它发数据，它试图同步给 B。
- 但它永远凑不齐 3 票（总共5个节点，需要3票）。
- 结果：A 收下的数据永远是 Uncommitted，无法响应客户端成功。
新 Leader (C) 的崛起：
- 在 [C, D, E] 分区，C 发现联系不上 A，发起选举。
- C 拿到 C, D, E 的 3 票，成为新 Leader（Term 增加）。
- Client 连接到 C，写入数据。C 能同步给 D 和 E，成功提交。
网络恢复（真相大白）：
- 分区消失。A (Term 1) 遇到了 C (Term 2)。
- 规则：Term 小的自动退位。
- 结果：A 发现自己任期旧，立马变为 Follower。它会清空自己那些未提交的“脏数据”，同步 C 的最新数据。