ZAB协议和Paxos算法

前言
在上一篇文章Paxos算法浅析中主要介绍了Paxos一致性算法应用的场景，以及对协议自己的介绍；Google Chubby是一个分布式锁服务，其底层一致性实现就是以Paxos算法为基础的；但这篇文件并非介绍Chubby，而是介绍了一个和Chubby拥有相似功能的开放源码的分布式协调服务Zookeeper，以及Zookeeper数据一致性的核心算法ZAB。

Zookeeper简介
Zookeeper是一个分布式数据一致性的解决方案，分布式应用能够基于它实现诸如数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等功能。Zookeeper致力于提供一个高性能、高可用、且具备严格的顺序访问控制能力的分布式协调系统。
考虑到Zookeeper主要操做数据的状态，为了保证状态的一致性，Zookeeper提出了两个安全属性:
1.全序（Total order）：若是消息a在消息b以前发送，则全部Server应该看到相同的结果
2.因果顺序（Causal order）：若是消息a在消息b以前发生（a致使了b），并被一块儿发送，则a始终在b以前被执行。
为了保证上述两个安全属性，Zookeeper使用了TCP协议和Leader：
经过使用TCP协议保证了消息的全序特性（先发先到），
经过Leader解决了因果顺序问题：先到Leader的先执行，可是这样的话Leader有可能出现出现网络中断、崩溃退出与重启等异常状况，这就有必要引入Leader选举算法。
而ZAB(Zookeeper Atomic Broadcast即Zookeeper原子消息广播协议)正是做为其数据一致性的核心算法，下面介绍一下ZAB协议。

ZAB协议
ZAB协议包括两种基本的模式：崩溃恢复和消息广播
当整个服务框架在启动过程当中，或是当Leader服务器出现网络中断崩溃退出与重启等异常状况时，ZAB就会进入恢复模式并选举产生新的Leader服务器。
当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步以后，ZAB协议就会退出崩溃恢复模式，进入消息广播模式。
当有新的服务器加入到集群中去，若是此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器会自动进入数据恢复模式，找到Leader服务器，并与其进行数据同步，而后一块儿参与到消息广播流程中去。
以上其实大体经历了三个步骤：
1.崩溃恢复：主要就是Leader选举过程
2.数据同步：Leader服务器与其余服务器进行数据同步
3.消息广播：Leader服务器将数据发送给其余服务器

下面具体看看这三个步骤
1.消息广播
ZAB协议的消息广播过程使用的是一个原子广播协议，相似二阶段提交(2PC/3PC究竟是啥)，具体能够看来源网上的一张图片：

客户端的请求，Leader服务器为其生成对于的Propose，并将其发送给其余服务器，而后再分别收集选票，最后进行提交；在广播Propose以前，Leader会为这个Propose分配一个全局单调递增的惟一ID，称之为事务ID(ZXID)；因为ZAB协议须要保证每个消息严格的因果关系，所以必须将每个Propose按照其ZXID的前后顺序来进行排序与处理。
具体作法就是Leader为每个Follower都各自分配一个单独的队列，而后将须要广播的Propose依次放入队列中。

2.崩溃恢复
消息广播中若是Leader出现网络中断、崩溃退出与重启等异常，将进入崩溃恢复，恢复的过程当中有2个问题须要解决：
1.ZAB协议须要确保那些已经在Leader服务器上提交的事务，最终被全部服务器都提交
2.ZAB协议须要确保丢弃那些只在Leader服务器上被提交的事务
针对以上两个问题，若是让Leader选举算法可以保证新选出来的Leader服务器拥有集群中全部机器最高编号(ZXID)的Propose，那么就能够保证这个新选出来的Leader必定具备全部已经提交的提案；若是让具备最高编号的机器成为Leader，就能够省去Leader服务器检查Propose的提交和抛弃了。

3.数据同步
Leader服务器会为每一个Follower服务器都准备一个队列，并将那些没有被各Follower同步的事务以propose消息的形式逐个发送给Follower服务器，并在每一个消息的后面发送一个commit消息，表示提交事务；等到同步完成以后，leader服务器会将该服务器加入到真正的可用Follower列表中。
崩溃恢复中提到2个问题，看看如何解决ZAB协议须要确保丢弃那些只在Leader服务器上被提交的事务：
事务编号ZXID被设计为一个64位的数字，低32位是一个简单的递增计数器，高32位是Leader周期的epoch编码，每当选举产生一个新的Leader服务器，就会从这个Leader服务器上取出本地日志中最大事务propose的ZXID，而后解析出epoch，最后对epoch加1；低32位就从0开始从新生成新的ZXID。ZAB协议经过epoch编号来区分Leader周期变化的策略，来保证丢弃那些只在上一个Leader服务器上被提交的事务。

Zab与Paxos
Zab的做者认为Zab与paxos并不相同，只因此没有采用Paxos是由于Paxos保证不了全序顺序：
Because multiple leaders can propose a value for a given instance two problems arise.
First, proposals can conflict. Paxos uses ballots to detect and resolve conflicting proposals.
Second, it is not enough to know that a given instance number has been committed, processes must also be able to fi gure out which value has been committed.
Paxos算法的确是不关心请求之间的逻辑顺序，而只考虑数据之间的全序，但不多有人直接使用paxos算法，都会通过必定的简化、优化。

Paxos算法优化
Paxos算法在出现竞争的状况下，其收敛速度很慢，甚至可能出现活锁的状况，例如当有三个及三个以上的proposer在发送prepare请求后，很难有一个proposer收到半数以上的回复而不断地执行第一阶段的协议。所以，为了不竞争，加快收敛的速度，在算法中引入了一个Leader这个角色，在正常状况下同时应该最多只能有一个参与者扮演Leader角色，而其它的参与者则扮演Acceptor的角色。
在这种优化算法中，只有Leader能够提出议案，从而避免了竞争使得算法可以快速地收敛而趋于一致；而为了保证Leader的健壮性，又引入了Leader选举，再考虑到同步的阶段，渐渐的你会发现对Paxos算法的简化和优化已经和上面介绍的ZAB协议很类似了。

总结
Google的粗粒度锁服务Chubby的设计开发者Burrows曾经说过：“全部一致性协议本质上要么是Paxos要么是其变体”。这句话仍是有必定道理的，ZAB本质上就是Paxos的一种简化形式。

我的博客：codingo.xyz