Raft 共识算法
什么是 Raft？
Raft 是一种为了管理复制日志的共识算法，由 Diego Ongaro 和 John Ousterhout 在 2013 年设计。它的主要目标是提供一个更容易理解的共识算法，同时保持与 Paxos 算法相同的可靠性和性能。
ETCD、Consul 等知名的分布式系统都采用了 Raft 算法作为其共识机制。
文章目录
- [Raft 共识算法](#Raft 共识算法)
-
- [什么是 Raft？](#什么是 Raft？)
- [Raft 的核心概念](#Raft 的核心概念)
- 服务器状态
- 领导者选举
- 日志复制
- [如何学习 Raft 算法（适合小白）](#如何学习 Raft 算法（适合小白）)
- [Raft 与 Paxos 的比较](#Raft 与 Paxos 的比较)
- 常见分布式系统使用的共识算法
-
- [ZAB 协议与 Raft 的区别](#ZAB 协议与 Raft 的区别)
- 总结
Raft 的核心概念
Raft 将共识问题分解为三个相对独立的子问题：
- 领导者选举（Leader Election）：当现有领导者失效时，必须选出一个新的领导者
- 日志复制（Log Replication）：领导者必须从客户端接收日志条目，并将它们复制到集群中的其他服务器
- 安全性（Safety）：如果任何服务器已经应用了一个特定的日志条目到其状态机，那么其他服务器不能在同一个日志索引位置应用不同的命令
服务器状态
在 Raft 中，服务器可以处于三种状态之一：
- 领导者（Leader）：处理所有客户端请求，如果客户端联系追随者，追随者会将请求重定向给领导者
- 追随者（Follower）：被动状态，不会发起请求，只响应来自领导者或候选人的请求
- 候选人（Candidate）：用于选举新领导者的中间状态
领导者选举
Raft 使用心跳机制触发领导者选举。当服务器启动时，它们都是追随者状态。只要追随者从领导者或候选人那里接收到有效的 RPC，它就会保持追随者状态。
如果追随者在一段时间内（称为选举超时）没有收到通信，它会假设没有可用的领导者，并开始选举：
- 追随者增加当前任期号并转换为候选人状态
- 候选人给自己投票并向其他服务器发送请求投票的 RPC
- 候选人保持候选人状态，直到以下三种情况之一发生：
- 它赢得选举（获得大多数服务器的投票）
- 另一个服务器成为领导者
- 一段时间过去没有选出领导者
日志复制
一旦选出领导者，它就开始为客户端请求提供服务。每个客户端请求包含一个要被复制状态机执行的命令：
- 领导者将命令附加到其日志中作为新条目
- 领导者并行发送 AppendEntries RPC 给追随者
- 当条目被安全复制后，领导者应用该条目到其状态机并返回结果给客户端
- 如果追随者崩溃或运行缓慢，领导者会无限重试 AppendEntries RPC
如何学习 Raft 算法（适合小白）
作为初学者，以下是学习 Raft 算法的建议步骤：
-
理解问题背景：先了解分布式系统中为什么需要共识算法
-
可视化学习 ：访问 Raft 可视化网站，这个交互式演示能直观地展示 Raft 的工作原理
-
阅读简化版论文 ：Raft 论文的作者专门为了易于理解而设计了这个算法，可以从 Raft 论文 开始
-
动手实践：
- 尝试用自己熟悉的编程语言实现一个简单版本的 Raft
- 或者研究 etcd 的源代码中 Raft 的实现
-
逐步深入：
- 先理解基本的领导者选举和日志复制
- 然后学习成员变更、日志压缩等高级特性
-
参考资源：
Raft 与 Paxos 的比较
Raft 和 Paxos 都是解决分布式共识问题的算法，但 Raft 被设计为更容易理解和实现：
| 特性 | Raft | Paxos |
|---|---|---|
| 设计目标 | 可理解性 | 理论完备性 |
| 复杂度 | 相对简单 | 复杂 |
| 角色划分 | 明确（领导者、追随者、候选人） | 不明确 |
| 实现难度 | 较低 | 较高 |
| 使用案例 | etcd, Consul | Chubby, Spanner |
常见分布式系统使用的共识算法
不同的分布式系统选择了不同的共识算法来保证一致性：
| 分布式系统 | 共识算法 | 特点 |
|---|---|---|
| etcd | Raft | 易于理解，强领导者模型 |
| Consul | Raft | 易于理解，强领导者模型 |
| Zookeeper | ZAB | 类似于 Raft，但有所不同 |
| Chubby | Paxos | 理论完备，实现复杂 |
| Spanner | Paxos | 理论完备，实现复杂 |
ZAB 协议与 Raft 的区别
ZAB (Zookeeper Atomic Broadcast) 协议是 Zookeeper 使用的共识算法，与 Raft 有一些相似之处，但也有明显区别：
-
相似点：
- 都使用强领导者模型
- 都有类似的领导者选举机制
- 都通过日志复制来保证一致性
-
不同点：
- ZAB 使用的是"恢复模式"和"广播模式"两个阶段
- ZAB 的领导者选举算法细节不同
- ZAB 协议设计更早，而 Raft 是为了可理解性而设计的
对于初学者来说，理解 Raft 后再学习 ZAB 会更容易，因为 Raft 的设计初衷就是为了易于理解。
总结
Raft 通过将复杂的共识问题分解为更易于理解的子问题，并引入了强领导者模型，使得分布式系统中的共识算法变得更加清晰和易于实现。这也是为什么 etcd 等现代分布式系统选择 Raft 而非 Paxos 作为其共识算法的原因。
对于初学者来说，理解 Raft 是进入分布式系统世界的一个很好的起点。通过可视化工具和简化的解释，即使没有深厚的分布式系统背景，也能逐步掌握这个重要的算法。
ETCD 用了哪个共识算法。