ZAB协议剖析

定义

ZAB 协议是为分布式协调服务 ZooKeeper专门设计的一种支持崩溃回复的原子广播协议。
 变量概念
在了解ZAB协议之前，我们需要先有下面这几个变量的概念：

    事务表示：epoch
    数据集合：L
    主服务：Leader
    从服务：Follower
 

描述

ZK主要是依赖ZAB协议来实现分布式数据一致性。我们能够想象为了实现这种分布式的一致性。ZK会如何实现呢？一种主备模式的系统架构，类似于redis的主从模式，来保证各个副本之间的一致性。有人会想，既然是主备的模式，是不是又会带来下一个问题，如果主挂了是不是就完蛋了。既然能够作为分布式协调服务的非常重要的服务，那肯定想到了这个问题。ZAB协议有崩溃恢复的机制。这个机制是否和redis的哨兵模式一样，这个我们可以深入的去研究一下。ZAB协议是整个ZooKeeper框架的核心所在，其规定了任何时候都需要保证只有一个主进程负责进行消息广播，而如果遇到主崩溃了，就重新选举出一个新的主进程。
 

ZAB三阶段

下面我们从三个阶段来了解ZK的崩溃恢复，同时其中也透漏了ZK的广播等重要的策略。
 

 发现

发现过程其实就是我们说的Leader选举过程。这个地方可以类比于redis的哨兵模式来学习和研究。
首先是投票进行Leader选举，这是个复杂的过程，其中包括sid、事务zxid等进行综合评定来选举出主服务。
这时候准Leader就评选出来了。其实过程也比较简单：

 1. Follow发送自己最后的事务Proposal的epoch给准Leader；
 2. 准Leader根据所有的F的epoch找到最大的然后加1后生成新的epoch' 然后发送给过半F的epoch；
 3. Follow得到new的epoch后把这个最新的作为自己的epoch。同时返回准Leader ACK；
 
上面这个三个步骤其实都是保证过半Follow来进行的。当Leader L接收到过半的Follower的确认消息ACK之后，Leader L就会从过半的服务器中选举出一个Follow F并使用其作为初始化集合的Ie'。
 

同步

所谓同步，那就是同步数据，在完成发现过程，这个过程确定了准Leader和Follow L。那就是要所有集群
中的ZK都同步到Follow L中确定的初始化的集合状态。下面是同步的过程：
        

 1. 准Leader将新的epoch e'和数据集合Ie’使用消息的方式发送给所有的Follow，Follow会在自己的接收队列中接收到消息；
 2. Follow根据得到的NEWlEADER(e', le')，来进行同步操作，根据e'来确定是否进行本轮循环和数据同步，如果不等于e'直接进入下一轮循环，直到到e'和本身的e'相等就进入循环操作，然后进行数据同步；
 3. 一样当过半的Follower针对上面1中发送的消息处理后，会对本次事务执行commit操作，这个操作是commit是向Leader发起的。这时Leader完成第二阶段；
 4. Leader得到过半的Follower的commit操作之后就会执行提交操作，这样同步操作完成。
 

广播

同步完成之后，这个时候基本所有服务器也就完成数据一致性了。那么这个时候ZAB协议就要开始新的数
据广播了。这个时候Leader就会开始接受Follower发送过来的广播请求。然后把该请求广播给所有的Follower。

 1.  准Leader收到客户端新的事务请求后，生成新的事务Proposal，然后根据ZXID的顺序来生成向所有Follower发送的提案<e', <v,z>>；
 2. Follower收到新的消息后，根据ZXID的次序依次加到自己的接收队列中，然后反馈给Leader；
 3. Leader收到过半的Follower的ACK之后，表示广播成功了，这个时候Leader再次发起提交请求给所有的Follower，要求Follower进行事务提交；
 4. Follower收到Leader的提交命令之后，开始提交自己的事务操作，提交事务前必定确定上一个事务已经提交了的。