上一章简单介绍了ZAB协议的基本定义，以及遵守ZAB协议的服务器运行时的两种模式。本章将深入讲解ZAB协议。
系统模型
ZAB协议构建的分布式系统，通常是由一组具有各自存储设备的进行组成，各进程之间通过相互通信来传递消息。当一个进程能够正常工作，则称其处于上线状态；当一个进行崩溃或者由于网络等原因导致其与其他进行失去联系，则称其处于下线状态。当集群中有超过一半的进程处于上线状态，集群就可以正常工作了。
ZXID
由上一章我们知道，在Leader服务器广播事务请求之前会为其分配一个全局唯一的事务ID，即ZXID。ZXID是一个64位的数字，其中低32位可看作一个简单的单调递增计数器，对于每个客户端事务请求，Leader服务器在产生新的事务提议时，都会对其进行加1操作。高32位代表Leader周期epoch（纪元），每当选举产生一个新的Leader都会从本地日志中取出最大事务提议的ZXID，解析出epoch后，对其进行加1操作，然后将低32位置0。通过epoch编号，可以有效的避免不同的Leader服务器使用相同的ZXID提出不同的提议，简化了数据恢复流程。
算法描述
遵循ZAB协议的每一个进程有四个执行阶段：选举、发现、同步、广播，这三个阶段循环执行，每一个循环就是一个主进程周期。
选举：在集群刚启动或者Leader崩溃退出时，集群中的Follower节点会进行Leader选举，得到超过半数节点票数的服务器就可以称为准Leader。选举过程后续介绍。
发现：发现最大的事务提议的epoch值。
1.Follower服务器将自己最后接收到的事务提议的epoch值e发送给准Leader服务器。
2.当准Leader服务器接收到过半服务器发送的epoch后，会从中选出最大值，然后加1，得到e'，然后将e'发送给Follower服务器。
3.当Follower服务器接收到来自准Leader服务器的新的epoch值e‘后，如果当前的epoch值小于e',就会将其赋值为e'，并向准Leader发送反馈信息，信息中包含Follower处理的最后一个事务提议的epoch值以及历史事务提议集合。
4.当准Leader服务器收到过半Follower服务器的反馈信息后，会从中选出epoch最大或者ZXID最大的Follower服务器，使用其做为初始化事务集合。
同步：将发现阶段获得的初始化事务集合中的事务在Follower服务器中进行同步。
1.准Leader服务器将最新的epoch值e'与初始化事务集合发送给Follower服务器。
2.Follower服务器接收到消息后，如果发现其epoch值小于e'，直接进入下一轮循环，如果epoch值相同，则Follower服务器接收并处理初始化事务集合中的事务。处理完成后反馈信息给准Leader服务器。
3.当准Leader接收到过半来自Follower服务器的反馈信息后，会向Follower服务器发送Commit消息。
4.当Follower服务器接收到来自准Leader服务器的Commit消息后，会将初始化事务集合中的事务进行提交。
广播：同步完成后，就可以进入广播模式，接收客户端新的事务请求了。
1.Leader服务器接收到客户端的事务请求后，会生成对应的事务提议，并根据ZXID的顺序向所有Follower服务器发送提议。
2.Follower服务器根据消息接收的先后顺序依次处理事务提议，处理完成后再反馈给Leader服务器。
3.Leader服务器收到超过半数的Follower服务器对此提议的反馈后，会发送commit消息给所有Follower服务器，来进行事务的提交。
4.Follower服务器接收到Leader服务器的commit消息后，提交事务。
正常情况下，会一直运行在广播阶段，如果出现Leader服务器崩溃或网络等其他原因导致Leader服务器与Follower服务器失去联系，就会进入选举阶段重新选举Leader。
运行状态
根据算法描述，每一个进程都有可能处于以下三种状态之一：
LOOKING：Leader选举阶段。
LEADING：Leader服务器做为主进程。
FOLLOWING：Follower服务器和Leader服务器保持同步。
当集群中机器启动时，所有进程初始状态都为LOOKING状态，处于LOOKING状态的进程会试图选举出一个Leader。当选举出Leader后，Leader进程会切换到LEADING状态，而其他进程则会切换到FOLLOWING状态，并与Leader保持同步。当Leader由于崩溃等原因失去领导地位时，其他Follower进程会切换到LOOKING状态重新进行选举。