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 |