ACK
ZAB包括两种基本模式，分别是奔溃恢复和消息广播。
FIFO
Propose
高32位代表了Leader的唯一性
Leader ID
Leader与Follower都有一一对应的消息队列，用于保证操作的顺序性，根据ZXID进行先后排序处理。
以事物日志形式写进磁盘
写入成功
……
Follower
基于这样的策略：当Foliower连接上Leader之后，Leader服务器会根据自己服务器上最后被提交的ZXID和Follower上的ZXID进行对比，要么回滚，要么与Leader同步。
Commit
崩溃恢复假设1：Leader在复制数据给所有follower之后崩溃，怎么办？假设2：Leader在收到ACK并提交了自己，同时发送了部分commit出去之后崩溃怎么办？针对这些问题，ZAB定义了两个原则： 1、ZAB协议确保那些已经在Leader提交的事务最终会被所有服务器提交。 2、ZAB协议确保丢弃那些只在Leader提出/复制，但没有提交的事务。所以ZAB设计了一个选举算法，能够确保提交已经被Leader提交的事务，同时丢弃已经被跳过的事务。针对这个要求，让Leader选举算法保证选举出来的Leader服务器拥有集群中的最大ZXID的事务，这样就可以保证新选举出来的Leader一定具有所有已经提交的提案，并且这样可以省去Leader服务器检查事务的提交和丢弃工作。
事务 ID
过半ACK
Leader
生成Proposal
低32位代表了事务的唯一性
Leader服务器维护了可用Follower的列表
文本
64位ZXID
Request
Multi-Paxos实现一系列值的共识，不关心最终达成共识的值是什么，即不关心顺序性，而ZAB实现了操作的顺序性。ZAB基于主备模式的原子广播协议，可以理解为广播一组消息，消息的顺序是固定的。整个消息广播协议基于具有FIFO特性的TCP协议来进行网络通讯的，能够很容易地保证消息广播过程中消息接收与发送的顺序性。
为Proposal分配ZXID
ZXIDLeader服务器处理或丢弃事务都是依赖ZXID的，那么ZXID如何生成？ZXID是一个64位的数字，其中低32位可以看作是一个简单的递增计数器，而高32位则代表了Leader服务器上取出本地日志中最大事务Proposal的ZXID，并从该ZXID中解析出来的epoch值然后+1。
消息广播所有副本的数据都以主节点为准，如果主节点发生故障，数据最完备的节点将当选主节点。类似二段提交，但并不是二段提交，因为Leader收到过半Follower的ACK后即可Commit（二段提交要收到全部ACK恢复YES）
