Zookeeper协议
Zookeeper是采用一种称为Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息广播协议）作为数据一致性的核心算法。支持崩溃恢复的原子广播协议。
Zookeeper采用的是主备模式的系统架构，通过ZAB协议保证各副本数据一致性。通过心跳检查机制感知彼此。
- Zookeeper通过唯一一个Leader服务器接受并处理客户端所有的事物请求。在将Leader服务器数据的状态变更以事物Proposal的形式广播到所有的副本。通过过半理论实现。称为（
消息广播） - 因事物存在依赖关系，所以需要保证事物的顺序执行。通过ZAB协议保证一个全局的变更序列被顺序执行。
- Leader服务器可以出现奔溃退出或重启现象，因此，ZAB协议还需要做到当Leader服务器出现异常，依旧能够正常工作。（
奔溃恢复）
消息广播
ZAB协议的消息广播过程使用的是一个原子广播协议，Leader服务器会为每个事物请求生成对应的Proposal来进行广播，并且为事物Proposal分配一个全局单调递增的唯一ID（ZXID，事物ID）。
为了保证事物的因果关系，因此每个事物Proposal必须按照其ZXID的先后顺序来进行排序与处理（FIFO，先进先出队列）。
Leader服务器为会每个Follower服务器分配一个单独的队列，然后将需要广播的事物Proposal依次放入该队列中，并且根据FIFO策略进行消息发送，每个Follower服务器在接受到这个事物Proposer之后，会将事务以日志形式写入到本地磁盘中，并且在成功写入后反馈给Leader服务器一个ACK响应，当Leader服务器接受到超半数Follower的ACK响应后，就会广播一个Commit消息给所有的Follower服务器一通知进行事物提交，同时Leader自身也会完成对事物的提交，每个Follower服务器接受到Commit消息后，完成对事物的提交。
奔溃恢复
- 能够确保已经在Leader提交过的事物Proposal（提案）。
- 丢弃那些只在Leader生成事物Proposal（提案），且没有被Leader提交的事物Proposal（提案）。
- 被选举出来的Leader服务器拥有集群中所有服务器最大编号（即已提交事物Proposal（提案）最大的ZXID）的事物Proposal。那么就可以确保Leader一定具有所有已提交的事物Proposal（提案）。
数据同步
在选举完Leader之后，Leader服务器首先会确定事物日志中的所有Proposal是否都已经被集群中过半的服务器提交，即是否完成数据同步。
Leader需要确保能够和所有Follower正常通信，在为每一个Follower创建一个事物队列，将那些没有被Follower服务器同步的事物以Proposal消息的形式逐个发送给Follower，并在Proposal消息后面紧接着再发送一个Commit消息，以表示该事物已经别提交。等Follower同步完Leader的数据后，Leader服务器才会将该Follower服务器加入到真正可用的Follower列表中。
更加ZIXD设计策略，包含上一个Leader周期中尚未完成的事物Proposal的服务器启动时，其肯定无法称为Leader，因集群服务器中一定包含一个更大的ZXID。
当这台服务器加入到集群中，以Follower角色连接上Leader服务器之后，Leader服务器会根据自己服务器上最后被提交的Proposal来和Follower服务器的Proposal进行比对，比对的结果当然是Leader会要求Follower进行一个回退操作，回退到一个已经被集群中过半服务器提交的最新的事物Proposal（当前服务器存在的事物Proposal）。
ZIXD设计
ZXID是一个64位的数字，分为低32位和高32位。
低32位
是一个简单的单调递增的计数器，针对客户端的每个事物请求，Leader服务器在生成一个新的事物Proposal的时候，都会对该计数器进行加1.
高32位
代表Leader周期epoch的编号，每当选举生产一个新的Leader服务器，就会从这个Leader服务器上取出本地日志中最大的事物Proposal的ZXID，并从ZIXD中解析出对应的epoch值，然后在堆其加1操作，之后就会以此编号作为新的epoch，并将低32位置0来开始生产新的ZIXID。
小结
ZAB协议的用于构建一个高可用的分布式数据主备系统，
Paxos算法是用于构建一个分布式一致状态系统。