Paxos、Raft 和 ZAB 分布式算法-跑的比公交车快

1. Paxos 算法

1.1. 核心思想：

Paxos 是一种分布式一致性算法，它的提出就是为了解决多个节点之间就某个值达成一致的问题，即保证分布式系统中的多个副本能够对同一值进行一致的决策。Paxos 的基本步骤包括：

提议阶段（Propose）：

提议者（Proposer）选择一个提案编号，并将该提案及编号发送给一组接受者（Acceptor）。

承诺阶段（Promise）：

接受者收到提案后，如果提案编号大于它之前承诺过的编号，它会承诺接受这个提案，并返回之前接收过的最大提案编号及值（如果有）。

决定阶段（Decide）：

如果某个提案获得大多数接受者的承诺，则该提案被认为是最终决定，所有节点都同意这个提案。

1.2. 优缺点：

优点：Paxos 是非常理论上严谨的一致性算法，能保证在网络分区和节点失败的情况下仍然能够达到一致性。
缺点：实现复杂，难以理解，且性能较差，尤其是在节点数量较多时，协议的消息传递和协调成本较高。

2. Raft 算法

2.1. 核心思想：

Raft 是一种相对较新的分布式一致性算法，比 Paxos 更易于理解，同时保持相同的安全性和一致性保证。Raft 通过以下几个步骤来实现一致性：

领导选举（Leader Election）：

Raft 中的所有节点分为领导者（Leader）和跟随者（Follower）。通过选举机制选举出一个领导者，领导者负责所有的日志条目的管理和分发。

日志复制（Log Replication）：

领导者将客户端的请求转化为日志条目，并将其复制到所有跟随者节点。当一个条目被大多数节点确认后，它就被提交并对外提供服务。

安全性（Safety）：

Raft 保证日志的一致性，即一个已提交的日志条目在所有节点中都是相同的。

日志压缩（Log Compaction）：

随着时间的推移，Raft 会定期进行日志压缩，以减少存储的开销。

2.2. 优缺点：

优点：Raft 比 Paxos 更易于理解和实现。它在理论上与 Paxos 等价，但其设计思想简单清晰，通常用于现代分布式系统，如较新版本的 Kafka 。
缺点：尽管易于实现，但 Raft 依赖于一个中心化的领导者，可能成为单点故障，且在领导者更换时会有一定的延迟。

3. ZAB 算法（Zookeeper Atomic Broadcast）

3.1. 核心思想：

ZAB 是专门为 Zookeeper 设计的原子广播协议，它是基于领导者选举和日志复制的一致性算法。ZAB 的核心思想分为两个阶段：

准备阶段（Proposal Phase）：

ZAB 通过领导者发起提案（Proposal），并将提案同步到所有备份节点。当大多数节点确认接收到该提案时，提案就被提交。

提交阶段（Commit Phase）：

当大多数节点确认收到提案后，领导者会通知所有节点将该提案提交并应用。

3.2. 优缺点：

优点：ZAB 针对 Zookeeper 的应用场景进行了优化，适用于强一致性的需求，能够高效地保证分布式锁、协调和一致性。
缺点：ZAB 只适用于 Zookeeper 环境，无法像 Raft 那样广泛应用于其他分布式系统。

4. 4. 总结

特性	Paxos	Raft	ZAB
设计目标	保证分布式系统的一致性	易于理解且实现，解决领导者选举等问题	专为 Zookeeper 设计，保证强一致性
核心机制	提案和承诺阶段，最终一致性	领导者选举、日志复制、提交	提案和提交阶段，原子广播协议
领导者概念	没有明确的领导者概念	有明确的领导者	有明确的领导者
理解与实现	难度较高，复杂	相对简单，易于实现	针对 Zookeeper，简单易理解
适用场景	一致性需求较强的场景	高可用、高性能分布式系统	高一致性需求的分布式协调系统
容错能力	高，能够在部分节点失败的情况下继续工作	高，但领导者可能成为单点故障	高容错，适用于 Zookeeper
性能	性能较低，尤其在节点数量多时	性能较好，适用于大规模分布式系统	针对 Zookeeper，性能优化

Paxos 是最早提出的一致性算法，理论上严谨，但实现复杂且性能较差。
Raft 提出了更易理解的方案，通过领导者选举和日志复制机制，既保证了理论的一致性，又改善了实现的复杂性，广泛应用于现代分布式系统。
ZAB 是专门为 Zookeeper 设计的协议，具有高一致性和原子广播特性，适用于强一致性需求的场景。

5. Raft 与 ZAB 协议的区别

5.1. Leader选举的区别

5.1.1. 选举触发条件

在 Raft 协议中，如果 Follower 在一段时间内没有收到 Leader 的心跳信息，就会主动进入候选人状态并启动新一轮选举，原因可能只是 Leader 节点繁忙而无法及时响应等情况。而在 ZAB 协议中，除了系统启动时，只有等到 Leader 故障、无法提供服务时才会进行选举。Raft 更偏向于积极选举，只要有可能就尝试选举新的领导者，而 ZAB 更倾向于保持现状，只有在确定领导者无法提供服务时才触发选举。

5.1.2. 投票规则

在 Raft 协议中，每个节点只能投票一次，并且投票给第一个请求投票的候选人。而在 ZAB 协议中，节点可能会改变自己的投票，投给 ZXID 更大的节点。所以 ZAB 不存在随机超时时间，虽然第一票都会投给自己，但后续如果发现其他节点的 ZXID 更大，就修改自己的选票。

5.1.3. 票数要求

在 Raft 协议中，候选人在获得超过半数的投票后成为 Leader。在 ZAB 协议中，新的领导者被选出后，还需要得到超过半数的节点的确认才能开始工作。

5.1.4. 选举 Leader 决定因素

在 Raft 协议中，选举过程严格按照轮次（任期）进行，每轮选举只能选出一位 Leader，选出 Leader 很大程度取决于随机的超时时间和日志最新。而在 ZAB 协议中，选举的结果主要取决于节点的 ZXID 以及节点编号。ZXID 最大的节点通常是最近处理过事务，日志较新。

简而言之，Raft 协议更侧重于通过随机的超时时间和日志一致性来进行选举，而 ZAB 协议则通过 ZXID（事务的处理顺序）和节点编号来选举出 Leader。

5.2. 日志复制机制的区别

ZAB 协议的日志复制机制中由于多了一个预提交步骤，因此相比 Raft 协议会有更高的延迟，特别是在高负载和大规模集群的情况下。Raft 通过简单的多数节点确认就可以完成日志提交，因此它通常具有更低的延迟。

警告：即将离开本站

目录CONTENT

Paxos、Raft 和 ZAB 分布式算法