Zab协议
Zab协议：Zab协议和分布一致性协议Paxos协议一样的，Zookeeper并没有使用Paxos分布式一致性协议，而是使用Zookeeper独有的Zab协议，这个协议也是保证了Zookeeper数据的一致性的，Zab协议有点类似于2pc协议,两段提交。
在Leader选举的过程中涉及到了Zab协议，Zab协议中涉及两个方面：
1、原子广播：为了保证数据的一致性。
比如说一个客户端的一个写的请求过来，这个请求会直接落在leader上。
写完之后会在Leader上面会生成一个日志，这个日志由Leader进行原子广播,就是通知所属下的follower节点，我的数据更新了(这个协议属于Proposal的提议)，你们马上去更新，所有的foolower更新之后会给Leader的一个回馈(发回一个ACK的确认的标志)。为了保证效率的话，只要Leader不挂掉的话，只要所有的foolower节点的一半加1的个数的节点反馈给Leader(由于网络的原因不会等到所有的从节点都给返回ACK)，这时Leader会向所有的在线foolower节点(不管是否发送ACK)发送commit请求，从而所有的foolower节点的日志文件的数据和Leader节点的日志文件同步，这就是Zab协议保证数据的一致性。
为什么不是所有的follow节点都返回ACK呢？
原因如下：有可能当Leader发出Proposal协议的时候，有可能follow节点挂掉了。这也就是follow节点不全返回ACK的原因。zk集群至少保证两台。
2、崩溃修复
当Leader崩溃的话，也就是挂掉的话，所有的follow节点会根据zxid和serverId的大小来选举出哪个是Leader。zxid事务最大的表明它已经执行了提议并且执行了commit的命令。一旦最大，说明它的数据是最新的。说明数据同步的开销就很小。这就是zab协议设计非常经典的地方。
然后客户端是根据Zab协议中的Following和Leading去判断哪个是Leader。
而Looking状态是还没有找到Leader。Observer有点类似于管家的角色，既不参与投票和选举，用来收集票数的和监控节点的状态的。当zk集群进行leader选举的时候，整个集群不对外提供服务的，observer状态将是wating状态。当leader选举出来的话，observer才是工作的状态。
