大数据_ 分布式一致 广播协议 Paxos, Zab , Raft 协议对比

其他参考：

分布式事务与一致性算法Paxos & raft & zab

https://blog.csdn.net/followmyinclinations/article/details/52870418

 

今天我对 Paxos, Zab, Raft 一一做了细致的了解。趁着还比较熟悉的时间节点，对这三个协议的异同做一个对比。

下面是这三个协议描述的链接地址：

希望在读这篇文章前，每个同学可以先做好充足的准备

 

Paxos 协议：

https://blog.csdn.net/u010003835/article/details/88643553

 

Zab 协议：

https://blog.csdn.net/u010003835/article/details/88540959

 

Raft 协议： 

https://blog.csdn.net/u010003835/article/details/88650121

 

 

本文仅仅是自己的一些愚见，欢迎大家指出不足之处。

 

 

 

3个协议相同的地方：

 

1.核心思想一致，都是过半投票的方式，来判断一个事务/协议 是否生效

2.都是 2PC算法的一种优化 .  2PC  Two Phase Commit

 

 

3个协议不同的地方：

 

Paxos :

 

   Paxos 可以说是 Zab,  Raft 之前提出过半数投票的概念的分布式一致的算法模型

1.Paxos 模型中有3个角色，Learner,  Acceptor, Proposer  ,  对于 ZAB / Raft 对角色进行了细化，

首先 Learner 与 Acceptor 进行了合并，在这2个协议中，都被称为 Follower.

Proposer 也即协议的提交者 都被称为 Leader.

 

 

2.Paxos 协议只是一个较为通用的模板，对很多地方没有细致的说明, 例如如何确保一个全局唯一的 Proposal 号。

而 Zab / Raft 对其进行了细致的描述。

Zab ZXID ,  高32位表示 epoch 周期， 低32位表示了事务编号

Raft Term 标识了全局唯一递增的序号。

 

 

3.Paxos 协议 最令人诟病的一点就是 描述了 可能会存在 多个 Proposer,  而 多个Propser 的协调这点，并没有很好的描述。

而 Zab ， Raft 都放弃了多 Proposer , 都设计为 单 Leader , 并由该 Leader 进行协调。

 

Zab 

  

1. Zab协议与 Paxos 区别在上面已经表述了，这里不再做表述

 

2.Zab / Raft 协议的区别， 这两个协议我认为大致的实现都是一样的，但也有区别

首先 Raft 协议提出了 HW 的概念， HW 即 kafka 1.0.0 之前的水位模型，也即 确认Commit ，跟总体 Index, 也即有一个指针表示当前已经确认的消息位置，另一个指向所有的消息

 

 

3.Zab / Raft 的Leader 选举阶段 （故障恢复 / 初始阶段）

故障恢复

Zab 协议采取的策略，是之前已经确认最大的 ZXID 会成为 Leader 

Raft 采取的策略是 最大日志长度 会成为 Leader,  而不是 commit index . 为什么不是 commit index , 因为很有可能之前的 Leader  的 commit index 最大。

 

初始阶段：

Raft 针对于选举冲突，设置了 加时竞票策略。

 

 

Raft 

 

Raft 与 Paxos, Zab 的区别见上面的描述。