Paxos vs Raft vs Zab：分布式一致性协议深度对比

在搭建分布式系统时，如何让多个节点就同一份数据达成共识，是绕不开的核心技术挑战。Paxos、Raft、Zab这三种算法，正是解决这一难题的经典方案。它们各有特点，共同构成了分布式一致性协议的核心框架。下面逐一解析它们的设计思路。

1. Paxos协议

谈及分布式共识，Paxos是公认的始祖。由Leslie Lamport在1990年提出的这个算法，堪称分布式领域的“九阴真经”，其思想深刻影响了后续几乎所有共识协议的设计。它要解决的问题是：在一个允许消息延迟、丢失甚至重复的异步网络中，如何让一组机器就某个值达成一致。

核心概念

要掌握Paxos，先要理解它的几个关键角色与概念：

提案（Proposal）：这是共识的目标，由一个全局唯一的提案编号和具体的提案值组成。编号决定了提案的优先级，是协议运作的关键。

提案者（Proposer）：可以将其视为“发起人”。它负责响应客户端请求，主动发起一轮提案。

接受者（Acceptor）：这是“投票委员会”。它们被动接收提案，依据规则决定是否接受，最终将结果告知学习者。

学习者（Learner）：相当于“记录员”。它们不参与投票，只负责最终学习并存储达成共识的结果。

基本流程

Paxos算法的精妙之处在于它的两阶段提交流程，类似一场严谨的议会表决：

第一阶段：准备（Prepare）。提案者向所有接受者发送一个带有新编号的Prepare请求。接受者收到后做出承诺：除非后续看到编号更大的提案，否则不再接受编号更小的提案。同时，它会告知提案者自己之前已接受过的编号最大的提案值。

第二阶段：接受（Accept）。如果提案者收到超过半数的接受者的积极回应，就可以正式发起Accept请求。此时提案值有一条重要规则：必须选用从接受者那里得到的、编号最大的那个提案值。如果接受者没有返回任何值，提案者才能使用自己的值。当这个Accept请求再次获得半数以上同意后，共识才算真正达成。

这个过程保证了，即使多个提案者同时发起提案，系统最终也只会确定一个值，并且该值一旦被多数派接受，就不会被更改。

特点

Paxos提供强一致性保证，具备高可用性和去中心化特性（任何节点都可以成为提案者）。它能容忍网络消息的重复、丢失、延迟和乱序，但其设计前提是网络中不存在“叛徒”（即非拜占庭式错误）。不过，Paxos原始论文艰深晦涩，工程实现颇具挑战，这也催生了后续更易理解的协议。

2. Raft协议

正因为Paxos难以掌握，2013年诞生的Raft协议明确将“易于理解”作为首要设计目标。它将复杂的共识问题清晰地拆分为三个相对独立的子问题：领导选举、日志复制和安全性，极大降低了学习和实现的难度。

核心概念

Raft引入了更直观的角色和状态：

领导者（Leader）：集群中唯一的“话事人”，所有客户端请求都由它处理，并由它负责将日志复制到其他节点。

跟随者（Follower）：完全被动的角色，只响应来自领导者和候选者的请求，相当于“备份”。

候选者（Candidate）：这是跟随者想“升职”为领导者时必须经历的中间状态。

任期（Term）：一个单调递增的编号，像逻辑时钟一样，用来标识领导者的“执政期”，是识别过期信息的关键。

基本流程

Raft的运行如同一场有秩序的民主选举与施政：

领导者选举：每个跟随者设置一个随机超时器。如果在这个时间内没有收到领导者的心跳，它就认为领导者“失联”，随即增加任期号，将自己转为候选者，并向其他节点发起投票请求。获得超过半数选票的候选者即晋升为新领导者。

日志复制：领导者将客户端请求封装成日志条目，通过AppendEntries RPC持续复制给所有跟随者。只有当日志条目被安全地复制到大多数节点的磁盘后，领导者才会提交它，并通知跟随者将条目应用到状态机。这个“大多数”原则是保证一致性的核心。

安全性：Raft通过一系列严格规则（例如，选举限制要求候选者的日志必须足够新）来确保已提交的日志条目绝不会被后续领导者覆盖，这是数据正确性的底线。

特点

Raft最大的优势在于简洁易懂，其论文甚至包含详细的状态机图示，极大促进了它在工业界的应用。它同样适用于非拜占庭容错的分布式系统，并且在工程实践中被证明非常可靠，Etcd、Consul等知名项目都采用了Raft。

3. Zab协议

如果说Paxos和Raft是通用型共识算法，那么Zab（Zookeeper Atomic Broadcast）则更像一个“定制化解决方案”。它是专门为著名的分布式协调服务Apache ZooKeeper设计的，核心目标是高效实现原子广播和崩溃恢复。

核心概念

Zab的架构与Raft类似，但也有其独特设计：

领导者（Leader）：与Raft类似，是唯一处理写请求的节点。

跟随者（Follower）：参与领导选举和事务投票，同时处理客户端读请求。

观察者（Observer）：一个特殊角色，它接收领导者的数据同步，处理读请求，但不参与投票。这在不影响写性能的前提下，极大提升了集群的读扩展能力。

ZXID：这是ZooKeeper事务的全局唯一ID，由64位数字组成，高32位是任期（epoch），低32位是计数器。它严格保证了所有事务的全局顺序。

基本流程

Zab协议的工作也分为两个主要阶段：

消息广播（原子广播阶段）：领导者为每个事务请求生成一个Proposal，并附带唯一的ZXID，然后广播给所有跟随者和观察者。跟随者将Proposal持久化到本地磁盘后，向领导者返回一个ACK。当领导者收到超过半数的ACK后，就广播一个Commit消息，要求所有节点提交该事务。

崩溃恢复：这是Zab设计的重点。当领导者崩溃后，集群进入恢复模式，选举出拥有最新、最完整日志（即最高ZXID）的节点作为新领导者。新领导者会与所有跟随者同步数据，确保所有已提交的事务都被持久化，并丢弃那些未达成多数派共识的提案，从而快速恢复到一个一致的状态。

特点

Zab协议深度耦合了ZooKeeper的主备（Leader-Follower架构），其设计高度优化了崩溃恢复的速度，这对于一个协调服务至关重要。它通过ZXID和epoch机制，优雅地解决了“幽灵复制”等边界问题，确保即使在连续崩溃的情况下，集群也能保持数据的严格一致性。

总体而言，Paxos奠定了理论基础，Raft提升了工程可理解性，而Zab则展示了如何为特定系统（ZooKeeper）量身打造一个高效的共识核心。理解它们的异同，是设计和选用分布式系统组件时一项重要的基本功。

来源：互联网