分布式系统【四、Raft 算法与工程应用】

Raft 算法与工程应用

系列专题第四篇 · 分布式系统基础指南

---

一、引言

在上一章我们讲解了 Paxos 算法。虽然 Paxos 理论优雅，但实现复杂，工程化难度高。
为了解决这个问题，Diego Ongaro 在 2014 年提出了 Raft 算法，它与 Paxos 拥有相同的一致性保证，但设计上更易于理解与实现。

Raft 主要被应用在 Etcd、Consul、TiKV、RethinkDB 等系统，是目前工程界最广泛使用的一致性协议。

---

二、Raft 的设计目标

Raft 试图在以下几个方面改进 Paxos：

1. 更易理解：算法模块化，结构清晰。
2. 更易实现：更少的消息交互，Leader 驱动，流程明确。
3. 更易应用：特别适合日志复制与状态机系统。

---

三、Raft 的三个核心组成

1. Leader 选举（Leader Election）

   • 保证集群中始终有一个唯一的 Leader。

2. 日志复制（Log Replication）

   • Leader 负责将客户端请求写入日志，并同步到多数派 Follower。

3. 安全性（Safety）

   • 保证在任何时刻，系统只会提交一个一致的日志顺序。

---

四、Raft 算法详细流程

1. Leader 选举

• 节点有三种状态：Follower、Candidate、Leader。

• 所有节点初始为 Follower。

• 若 Follower 在一定时间内未收到 Leader 心跳，则转为 Candidate，发起选举。

• Candidate 广播投票请求：

  • 多数节点投票给它，则当选 Leader。
  • 选举失败则重新开始下一轮。

---

2. 日志复制

• Client 请求首先到达 Leader。
• Leader 将请求封装为日志条目，写入本地日志。
• Leader 并行发送 AppendEntries RPC 给所有 Follower。
• 一旦多数派 Follower 确认写入，Leader 将日志提交并应用到状态机，然后通知客户端成功。

---

3. 安全性保障

Raft 的关键安全规则：

• 选举限制：Candidate 必须拥有最新的日志才能当选 Leader。
• 日志匹配：如果两个日志条目拥有相同的索引和任期，则它们的内容一定相同。
• 提交规则：只有 Leader 自己的日志并被多数派复制时，才会标记为已提交。

---

五、Raft 的优势

• 简单易懂：论文中提供了动画与可视化演示。
• 高性能：Leader 驱动，减少 Prepare 阶段的开销。
• 广泛应用：Etcd、Consul、TiKV、CockroachDB 等核心系统都基于 Raft。

---

六、工程应用

1. Etcd

   • Kubernetes 的核心配置存储，依赖 Raft 保证一致性。
   • API Server 写请求先写入 Leader，复制到多数派后才提交。

2. TiKV

   • 分布式 Key-Value 存储，基于 Raft 实现 Region 复制与一致性。

3. Consul

   • 服务发现与配置管理，Raft 保证集群元数据一致性。

---

七、Raft 与 Paxos 对比

特性	Paxos	Raft
可理解性	难，论文抽象	易，分模块设计
消息复杂度	较高	较低
工程实现	难度大	工程界主流
典型应用	Chubby, ZooKeeper	Etcd, Consul, TiKV

---

八、总结

• Raft 是分布式一致性协议中最工程化的选择。
• 核心思想：Leader 选举 + 日志复制 + 安全性保障。
• 在工程界，Raft 已成为事实上的标准一致性协议。