什么是 Paxos和Raft

Raft 和 Paxos 是两种经典的分布式一致性算法（Consensus Algorithms），广泛应用于数据库、分布式系统、微服务架构中，用来确保在多个节点中即使有部分节点故障，系统仍然可以就“某一值”达成一致（即：分布式共识）。

它们不是区块链专属，但在联盟链、私有链或数据库复制系统中常被用来替代 PoW、PBFT 等共识机制。

---

一、什么是 Paxos？

定义：

Paxos 是一种保证在部分节点失效或网络延迟时，多个分布式节点能就某个值达成一致的协议，由计算机科学家 Leslie Lamport 提出。

场景背景：

• 服务器节点间无法完全信任；
• 网络可能延迟或断连；
• 仍需要 ** 选出“被大家同意的提案/值” ** 作为决策结果。

核心角色：

角色	说明
Proposer	提出提案（某个值）
Acceptor	接受并投票是否同意提案
Learner	接收投票结果，学习被选定的提案值

简化流程：

1. Proposer 发出编号 + 提案（比如提议设置主节点为A）
2. Acceptor 接收提案，若未承诺别的，就同意并承诺不接受编号更低的提案
3. 一旦超过半数 Acceptor 同意，该提案被采纳

Paxos 优点：

• 高一致性保证
• 理论基础扎实，已被数学证明正确

Paxos 缺点：

• 设计复杂，难以实现和理解
• 实际部署效率较低

---

二、什么是 Raft？

定义：

Raft 是 Paxos 的简化版、工程可落地版，由 Diego Ongaro 和 John Ousterhout 提出，目标是让分布式一致性“更容易理解和实现”。

被广泛应用于实际系统，如：etcd、Consul、TiKV、Kubernetes 组件、Hyperledger Fabric

核心理念：

Raft 通过**强主结构（Leader）**实现集群复制与共识。

三种角色：

角色	说明
Leader	唯一负责处理客户端请求并同步给其他节点
Follower	被动接收 Leader 的日志复制
Candidate	在选举期间自荐为 Leader 的节点

---

Raft 的工作流程

1. Leader 选举：

• 初始所有节点是 Follower；
• 若超时未收到 Leader 心跳包，会变成 Candidate 并发起投票；
• 获得过半选票的 Candidate 成为新的 Leader。

2. 日志复制：

• 客户端请求发送到 Leader；
• Leader 将请求作为日志广播给 Followers；
• 当日志被大多数节点确认，Leader 才提交它，客户端才认为“成功”。

3. 容错能力：

• 系统容忍 f 个失效节点，需至少 2f + 1 个节点运行。

---

三、Raft vs Paxos 对比

特性	Paxos	Raft
发明者	Leslie Lamport	Diego Ongaro 等
可读性	非常差	设计清晰，易懂易实现
系统结构	无 Leader（多数投票）	有 Leader（中心同步）
实际部署	少（理论研究多）	多（K8s、etcd、Fabric 等）
性能	中	高
容错性	高	高
应用	理论共识	工程共识

---

四、实际应用场景

应用系统	使用算法	场景说明
etcd（K8s 核心）	Raft	配置中心、服务发现
Consul	Raft	服务注册、KV存储
TiKV（PingCAP）	Raft	分布式数据库一致性
Zookeeper	Zab（类似 Paxos）	集群协调一致性
Hyperledger Fabric	Raft	区块链联盟链共识层之一（替代 Kafka）

---

总结对比表

对比项	Paxos	Raft
类型	分布式一致性算法	Paxos 实现变种
易用性	理论性强，复杂难懂	工程友好，广泛应用
共识模型	多数投票达成一致	强主结构，日志同步
吞吐性能	中	高
容错性	高	高
适合场景	研究、极端容错系统	企业分布式系统、联盟链

---

总结

名称	Paxos	Raft
核心作用	实现多个节点达成一致，保证数据一致性
应用领域	分布式数据库、分布式KV系统、区块链联盟链等
核心价值	即使部分节点宕机或网络不可靠，系统仍能保持一致