ZAB协议全程ZOOKEEPER AUTOMIC BROADCAST
zab协议类似于Paxos，但是paxos协议不能保证先提交的Proposer会被执行，同事也有可能会出现活锁的情况，zab协议改进了Paxos协议，Elect出Leader，只有Leader才能提交Proposer，同事集群内部Leader负责写请求，读操作会被负载到PC上，而且zab协议保证了如果Leader 挂掉之后能够快速保证选举出最新的Leader，而且最新的Leader是zk集群内部proposer zxid最大的那台pc，这样保证集群内部恢复的时候可以最快，同事保证了丢弃只有在Leader上提交的Proposer。
相比如Paxos协议，zab协议少了Prepare阶段，图中Follower对应Paxos中的Acceptor，Observers对应Paxos中的Learner
ZAB协议下面zk集群内部角色
设计特点：
1：最终一致性，client无论连接那个Server，展示给他的都是同一个试图，这也是zk最重要的一个特性
2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5.原子性：更新只能成功或者失败，没有中间状态。
6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
ZAB协议：
主要分为原子广播和崩溃恢复阶段
原子广播阶段：
就是zk对外提供服务的时候，Leader负责接收client的请求，广播给Follower，Observer负责学习，此处不再做赘述
崩溃恢复阶段：
zk中规定了节点的状态，又是那种Leading，Following，Looking三种，Leading就是Leader，Following就是Follower，Looking就是在Leader挂掉之后集群内部Server的状态，下面是一个状态切换图：
当节点处于Looking的时候就开始进行选举，具体的选举流程此处不再赘述，ZK中采用的FastLeaderElection算法
上面也说到了，在选举的时候，只有事务ID最高的那台server才能成为Leader
在选举出Leader之后，leader服务器会把之前的zxid解析出来，前32位加一作为新事务的前32位，后32位从0开始；
新的Leader会通过zxid和Follower进行对于，来达到数据同步的状态，当恢复到一致的时候，集群开始进入原子广播状态，其实这个过程很复杂，我这里只是很简单的说一下，有兴趣的可以自行百度
转载于:https://my.oschina.net/u/1034481/blog/823989