浅谈Zookeeper-ZAB协议原理

ZAB协议介绍

ZAB协议（Zookeeper Atomic Broadcast）时Zk中保证数据一致性的重要协议，是基于Paxos算法单独为Zk实现的协议。

ZAB协议是一种支持崩溃恢复和原子广播的协议，基于zab协议，zk实现了一种主备模式的系统架构，由单一的主进程来处理客户端的请求，并且为每个请求分配一个全局唯一单调递增的事务ID（zxid），然后由主进程将数据广播给副本进程上去。所以说zk是一个保证顺序一致性的服务。

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称之为Leader服务器，而余下的服务器称之为Follower服务器。Leader服务器负责将一个客户端事务请求转化为一个事务Proposal（提议），并将该事务提议分发给Follower，之后Leader等待Follower的ACK反馈，一但超过半数的Follower正确反馈，那么Leader将向所有Follower发送一个commit消息，要求Follower把前一个事务提议进行提交。

Zab协议的过程如下图所示：
zk服务器由三节点构成，1主2从，客户端所有的事务请求由Leader进行处理，并且通过广播发送给Follower副本。

ZAB协议基本特性

（1）高可用：由于采用主备模型，可以保证当Leader节点挂机或者网络分区后，集群依然工作对外提供服务。（当集群中超过半数节点存活，整个集群可用）

（2）数据一致性：一个事务请求只能由Leader节点处理，Leader节点将事务请求广播给副本节点。保证如果一个事务被提交成功，那么所有节点都应该被处理成功。

1、Zab协议确保在Leader服务器提交的事务最终被所有服务器提交
2、Zab协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。

（3）保证事务顺序：由于zk是树形目录结构，创建子节点时需要存在父节点，Zab要保证同一个Leader发起的事务按顺序执行，同时还要保证只有先前Leader的事务被执行之后，新的Leader才能再次发起事务。

ZAB协议核心

ZAB协议基本模式

ZAB协议有两种基本模式，分别为崩溃恢复和消息广播，接下来通过一个流程介绍两种模式分别是什么。

1. 服务器启动： 当服务器第一次启动时，整个集群服务没有Leader节点，则此时进入恢复模式并选举一个Leader节点，选举成功后其他节点与Leader保持状态同步，当过半的节点与Leader状态同步后则退出恢复模式，进入消息广播模式。
2. 服务器运行： 服务运行期间为消息广播模式阶段，客户端的每个事务提议请求（proposal）由Leader节点生成一个zxid转化为事务请求，然后通过消息广播发给Follower节点，当超过半数的Follower节点正确响应后，提交该事务。
3. 新节点加入： 当一个新的zk服务节点加入时，如果此时集群中存在Leader节点，那么将自动切换为数据恢复模式，与Leader节点进行数据同步，然后参与到消息广播中去。
4. Leader节点宕机、网络分区、超过半数节点状态不同步： 当出现上述中的情况时，那么整个ZK服务停止，由广播模式切换到崩溃恢复模式，然后经过选举、同步一系列操作后，再次进入新一轮消息广播模式中。

崩溃恢复与消息广播

ZXID：为每一个事务请求分配的单调递增唯一ID标识，其中低32位标识Leader任期的epoch编号，高32位标识该任期内的事务id。每次Leader选举epoch都会增加，事务id归零。

消息广播：
ZAB协议消息广播，是类似于一个两阶段提交协议实现的，整体分为三个步骤。
1、首先Leader收到客户端的数据更新请求后，转化为一个事务提议，然后向Follower节点发送数据变更请求。
2、当Follower接受到事务请求后，将事务以日志的形式写入本地磁盘，并且返回给Leader一个ACK响应。
3、当Leader收到超过半数（半数中包括Leader）的正确ACK响应后，发送该事务的提交请求commit给Follower。

其实在实际的通信过程中，Leader会为每个事务请求分配一个全局单调递增的ZXID，因此每个事务按照ZXID的顺序进行排序处理。Leader还会为每个Follower创建一个FIFO的队列，用来存放Leader的请求，这样可以保证每个事务的顺序执行，ZK不要求每个Follower执行完毕，只需要保证写入FIFO队列中即可。

崩溃恢复：
当Leader节点崩溃或下线时，还可能由于网络分区导致Leader失去与超过一半节点的连接时，此时进入到崩溃恢复模式。

ZAB协议为了保证程序的正确运行，此时需要通过Leader选举算法选举出一个新的Leader节点，同时能够让其他所有节点快速感知到新选举的Leader节点。

ZAB协议还要确保，无论出现任何问题都需要保证数据一致性，在崩溃恢复的过程中，可能会出现两种情况出现数据不一致。
P1：代表Proposal1事务的请求
C1：代表Proposal1事务的提交Commit

情况一：
当Leader发送C2的时候崩溃退出，那么ZAB协议需要保证P2最终能够在所有服务器上执行，否则会出现不一致。

情况2：
如果在崩溃恢复过程中，需要丢弃一个Proposal提案时，那么确保在崩溃恢复结算时跳过需要被丢弃的提案。

如下图所示，Proposal3 只有在Leader上提出后便发生崩溃，那么需要确保在集群恢复后，保证Proposal3被跳过，不会执行。

结合上面的案例，ZAB协议决定Leader选举算法必须满足已上两个条件：1、确保提交被Leader提交的事务；2、确保丢弃已经被跳过的事务；
在Leader选举阶段，通过选取具有最大事务编号zxid的为Leader节点，这样保证新的Leader具有最全的数据，并且Leader服务器需要确保每一个Proposal都被半数以上机器提交。

当Leader选举完毕后，则崩溃恢复进入到数据恢复阶段。当其他服务器感知到Leader服务器出现后，则从Leader服务器同步数据，

完成 Leader 选举后（新的 Leader 具有最大的zxid），在开始对外提供服务之前，Leader 服务器会首先确认事务日志中的所有的 Proposal 是否已经被集群中过半的服务器 Commit。

Leader 服务器需要确保所有的 Follower 服务器能够接收到每一条事务的 Proposal ，并且能将所有已经提交的事务 Proposal 应用到内存数据中。等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过啦并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中。

等到Follower服务器保持与Leader同步后，Leader就会将该机器加入到可用Follower列表当中，列表中超过过半机器后，则进入消息广播模式，开始对外提供服务。

ZAB协议内部原理

从算法角度描述，ZAB协议主要分为三个阶段，分别为发现、同步、广播，每一个进程都会循环执行三个阶段，一个循环称之为一个主进程周期。

阶段一 发现：
就是Leader选举阶段，该阶段选择具有最大zxid的服务器，并且会从过半Follower中选择最大的epoch然后+1 生成新的epoch发送给follower。

阶段二 同步：
该阶段，Leader将自己的epoch和事务集合发送给Follower，Follower判断自己的epoch是否和Leader一致，如果不一致说明自己还在之前的轮次，不参与同步，如果一致则会执行Leader的事务集合，然后返回给Leader响应。当Leader收到过半Follower的ACK响应后，会再次发送Commit信息。

阶段三 广播：
在完成同步阶段后，此时可以对外提供服务了，并且接受客户端新的事务请求，进入到广播流程。

小结：
ZK服务运行期间，会不断进行上述三个阶段的循环，每一次循环为一个周期。

总结

本文详细的描述了ZAB协议的原理和服务的运行阶段，以及模式的转换过程。但是没有详细说明Leader的选举算法，在下一篇文章中讲述。

ZK运行期间，每个进程都会处于三种状态之一：
LOOKING：Leader选举阶段
FOLLOWING：Follower与Leader保持同步状态
LEADING：Leader做为主进程领导状态

参考文献：
1、从paxos到Zookeeper分布式一致性原理与实践
2、https://www.jianshu.com/p/2bceacd60b8a