Raft 算法是一种分布式一致性算法，由 Diego Ongaro 和 John Ousterhout 在 2014 年提出，旨在解决 Paxos 算法复杂且难以理解的问题。Raft 设计目标是易于理解和实现，同时提供强一致性（CAP 中的 CP 系统），广泛应用于分布式系统中，如 etcd、Consul 和 TiDB。以下是对 Raft 算法的详细解释，包括其原理、流程、角色、优缺点及应用场景。
1. Raft 算法概述
- 目标：在分布式系统中达成共识，确保多个节点在不可靠网络环境中对某个值（如日志条目、状态更新）达成一致。
- 核心思想：通过 Leader 驱动的日志复制机制实现共识，将问题分解为易于理解的子任务：Leader 选举、日志复制和安全保证。
- 前提假设 ：
- 节点可能崩溃（非拜占庭故障），但不会恶意行为。
- 网络可能出现延迟、分区或消息丢失，但最终可达。
- 至少多数节点（>50%）正常运行以达成共识。
2. Raft 的角色
Raft 中每个节点在任意时刻处于以下三种角色之一：
- Leader（领导者） ：
- 负责处理客户端请求、协调日志复制、向 Follower 发送心跳。
- 系统中最多只有一个活跃 Leader。
- Follower（跟随者） ：
- 被动接收 Leader 的心跳和日志复制请求。
- 可响应投票请求，参与 Leader 选举。
- Candidate（候选者） ：
- 临时角色，节点在选举新 Leader 时进入此状态。
- 发起投票请求，尝试成为 Leader。
与 Paxos 的对比
| 特性 | Raft | Paxos |
|---|---|---|
| 易理解性 | 高，分解为选举和复制子问题 | 低，流程复杂，难以实现 |
| 角色 | Leader、Follower、Candidate | Proposer、Acceptor、Learner |
| 一致性 | 强一致性（CP 系统） | 强一致性（CP 系统） |
| 性能 | Leader 驱动，单点瓶颈 | Multi-Paxos 优化后性能相近 |
| 应用 | etcd、Consul、TiDB | Google Spanner、Chubby、ZooKeeper |