zookeeper中的一致性协议zab

关于一致性协议

说起分布式一致性协议的始祖，就不得不提到larmport大师发表的< The Part-Time Parliament>论文，但在这个论文中描述的paxos算法很长时间只停留在理论阶段，在实际的工程中又出现了很多的变种。Zookeeper的ZAB，Viewstamped Replication（VR），raft，multi-paxos，这些都可以被称之为Leader-based一致性协议。不同的是，multi-paxos leader是作为对经典paxos的优化而提出，通过选择一个proposer作为leader降低多个proposer引起冲突的频率，合并阶段一从而将一次决议的平均消息代价缩小到最优的两次，实际上就算有多个leader存在，算法还是安全的，只是退化为经典的paxos算法。而经典的paxos，从一个提案被提出到被接受分为两个阶段，第一个阶段去询问值，第二阶段根据询问的结果提出值。这两个阶段是无法分割的，两个阶段的每个细节都是精心设计的，相互关联，共同保障了协议的一致性。而VR,ZAB,Raft这些强调合法leader的唯一性协议，它们直接从leader的角度描述协议的流程，也从leader的角度出发论证正确性。但是实际上它们使用了和Paxos完全一样的原理来保证协议的安全性，当同时存在多个节点同时尝试成为leader或者不知一个节点认为自己时leader时，本质上它们和经典Paxos中多个proposer并存的情形没什么不同。

算法描述

和raft一样，zab中的角色也分别负责三个主要的职能，发起提议的leader，投标表决以及参加竞选的follower和没有任何投票及选举权的learner。与raft不同的是，zab用的是epoch和count的组合来唯一表示一个entry, 而raft用的是term和index的组合来确定一个entry，其中epoch和count的组合被称作zxid。

在 ZAB 协议的事务编号 Zxid 设计中，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期 epoch 的编号，每个当选产生一个新的 Leader 服务器，就会从这个 Leader 服务器上取出其本地日志中最大事务的ZXID，并从中读取 epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。

选举阶段

在这个阶段，zab协议可配置多种leader election算法，包括basic paxos的选举算法以及Fast Leader Election。
这个阶段结束之后，获得大多数选票的follower将成为准leader，这时候它还不是leader不能履行leader的职责，随后的同步阶段过后，他才能真正的履行leader的职责。

发现阶段

在这个阶段，followers 跟准 leader 进行通信，同步 followers 最近接收的事务提议。这个一阶段的主要目的是发现当前大多数节点接收的最新提议，并且准 leader 生成新的 epoch，让 followers 接受，更新它们的 acceptedEpoch
一个 follower 只会连接一个 leader，如果有一个节点 f 认为另一个 follower p 是 leader，f 在尝试连接 p 时会被拒绝，f 被拒绝之后，就会进入 Phase 0。

同步阶段

同步阶段主要是利用 leader 前一阶段获得的最新提议历史，同步集群中所有的副本。只有当 quorum 都同步完成，准 leader 才会成为真正的 leader。follower 只会接收 zxid 比自己的 lastZxid 大的提议。

广播阶段

Broadcast模式使用二阶段提交，但是简化了协议，不需要abort。follower要么ack，要么抛弃Leader，因为zookeeper保证了每次只有一个Leader。另外也不需要等待所有Server的ACK，只需要一个quorum应答就可以了。
到了这个阶段，Zookeeper 集群才能正式对外提供事务服务，并且 leader 可以进行消息广播。同时如果有新的节点加入，还需要对新节点进行同步。

值得注意的是，ZAB 提交事务并不像 2PC 一样需要全部 follower 都 ACK，只需要得到 quorum （超过半数的节点）的 ACK 就可以了。

回复阶段

在工程实现中通常会把发现阶段与同步阶段合并成一个恢复阶段

一致性保证

1. 全局有序：如果消息 a 在消息 b 之前被投递，那么在任何一台服务器，消息 a都会在消息 b 之前被投递。
2. 因果有序：如果消息 a 在消息 b 之前发生（a 导致了 b），并被一起发送，则 a 始终在 b 之前被执行。

VS Raft

raft的基于日志复制的状态机，对日志的要求是连续的，而zab则是由multi paxos延伸出来的，允许有日志空洞，所以zab对网络抖动的容忍性更高。
zab选举leader的过程非常严格，开始要经历准leader阶段，同步阶段之后才能开始真正的履行leader的职责。而相比于raft，raft的leader选举则相对宽松，所以在leader从宕机到重新加入集群的过程中，raft的情况要相对复杂得多。
关于心跳，raft只是单向的从leader到follower，在follower超时之后转变为candidate发起竞选，而zab实现了双向的数据流动，zab通过leader及follower都可以转变为candidate发出竞选。

其他

选举阶段中的Fast Leader Election可以参考这篇文章
https://zhuanlan.zhihu.com/p/27335748

参考资料

http://blog.xiaohansong.com/2016/08/25/zab/
https://zhuanlan.zhihu.com/p/25332350
https://feisky.xyz/distributed/zab.html
http://www.cs.cornell.edu/courses/cs6452/2012sp/papers/zab-ieee.pdf