1zab能够保证一个全局的变更序列被顺序应用
2zab协议包含两个模式：
崩溃恢复
消息广播
Zab协议必须设计这样一个选举算法：能够确保提交已经被leader提交的事务proposal,同时丢弃被跳过的事务Proposal
数据同步
所有运行服务器，要不成为leader,要不成为follower和leader进行同步
在zab协议的事务编号zxid,是一个64位数字，低32位是一个简单的单调递增计数器，高32位是代表leader周期epoch的编号
zab系统模型
进程组，状态有up状态，也有down状态，当集群中存在过半up状态组成的进行后，就可以进行正常的消息广播了
使用pi,pj分别表示进程组[]中两个不同进程，使用cij表示进程pi和pj之间的网络通信通道，满足如下两个基本条件
完整性
如何进程pj收到了来自pi的消息m,那么进程pi一定确实发送了消息m
前置性，
如果进程pj收到了消息m,那么存在这样的消息m`,如果m`是m的前置消息，那么pj务必先接收到消息m`,然后再接收到m,这样才能保证消息的顺序
主进程周期
为了保证每次广播出来的消息是一致的，必须确保zab协议只有在充分完成崩溃恢复阶段之后，新的主进程才可以开始生成新的事务消息广播。
事务，
各个进程都存在一个类似于transactions(v,z)这样的函数调用，来实现主进程对状态变更的广播，v表示事务内容，z表示事务标识，新旧事务id存在两种情况,不同事务周期epoch(z)<epoch(z') . 不同事务周期相同事务周期epoch(z)=epoch(z')且counter(z)<counter(z`)
zab协议包括两个过程，消息广播和崩溃恢复两个过程，细分成三个阶段，分别是发现，同步和广播
，将这一个循环称为一个主进程周期
1发现
leader选举过程，选举主进程，Leader F和Follower F工作流程如下：
F.1.1 Follower F将自己最后接受的事务proposal的epoch值 CEPOCH(Fp)发送给Leader L
L.1.1 接收来自过半Follower的 CEPOCH(Fp)消息后，准Leader L会生成NEWEPOCH(e')给过半Follower,
关于这个epoch值e',准leader L会从接收的所有CEPOCH(Fp)消息中选取最大的epoch值，然后进行加1操作，即为e'
F.1.2 Follower接收来自准Leader L的NEWEPOCH(e')消息后，如果检测到当前的CEPOCH(Fp)值小于e',将CEPOCH(Fp)赋值为e',同时向准Leader L反馈 Ack消息，反馈消息(ACK-E(Fp,hf))中，包含当前Follower的epoch CEPOCH(Fp)，以及该Follower历史事务Proposal集合：hf
当leader L接收到来自过半Follower的确认ack消息后，Leader L就会从过半服务器列表中选取出一个follower F ,使其作为初始化事务集合Ie'.
关于这个 Follower F的选择，它对于Quorum中其他任意一个Follower F',F需要满足以下两个条件中一个：
CEPOCH(F'p)<CEPOCH(Fp)
或
(CEPOCH(F'p)=CEPOCH(Fp))&(F'zxid滞后于Fzxid或F'zxid=Fzixd)
上面描述了发现这一个阶段的相关事宜
同步阶段
Leader L 和Follower F之间的交互流程：
L.2.1 leader L会将e'和le'以 NEWLEADER(e',ie') 消息发送给quorum中的follower;
F.2.1 Follower 接收到来自Leader L的NEWLEADER(e',le')消息后，如果Follower 发现CEPOCH(Fp)不等于e',那么直接进入下一轮循环，follower发现自己在上一轮 ，或者更上一轮，无法参与本轮的同步
如果CEPOCH(Fp)=e',那么follower 会执行事务应用操作，
L.2.2当leader接收来自过半follower针对newLeader(e',ie')的反馈后，就会向所有follower发送commit消息
F.2.2 当Follower收到来自leader中Commit消息后，依次处理并提交所有在ie'中未处理的事务
第二阶段 同步完成
开始第三阶段处理 广播
L.3.1 Leader L接收到客户端新的事务请求后，就会生成对应的事务proposal,并根据zxid的顺序向所有follower发送提案<e',<v,z>>其中epoch(z)=e'
F.3.1 Follower根据消息接收的先后次序来处理来自leader的事务proposal,并将它们追加到hf中，再反馈给leader.
F.3.2 当Follower F接收来自leader的commit<e',<v,z>>消息后，就会开始提交事务Proposal<e',<v,z>>.此时Follower F 必定已经提交了事务Proposal<v',z'>
运行过程中会一致运行阶段三进行消息广播过程，如果出现了Leader崩溃或其他原因导致leader缺失，那么会进入阶段一，重新选举新leader
zab协议三个阶段描述如下
在zab协议运行过程中，每个进程都会在leading,following 和looking状态之间不断转换
我们将可用leader定义如下：
如果一个准leader le接收来自过半的Follower进程针对le的NEWLEADER(e,le)反馈消息，那么le就成为周期e的leader
如果在指定超时时间内leader无法从过半服务器获取心跳信息，或者tcp本身断开了连接，那么leader就会终止当前领导周期，转换到looking状态，所有的follower也会放弃当前这个leader,之后follower进入新一轮的leader选举