初识Zookeeper
Zookeeper起初是阿帕奇的Hadoop的子项目，后来由于其高效、可靠、开源，后来发展成了阿帕奇的顶级项目。Zookeeper没有直接使用paxos算法，而是自创了ZAB协议（一致性广播协议：Zookeeper Atomic Broadcast）。
Zookeeper是一款分布式协调服务软件，主要用来解决分布式应用的一致性问题。目前基于它的软件有Hadoop、HBase、Storm、Solr、Disconf、Dubbo和Kafka等。
1. 软件特性
顺序一致性：同一个客户端发起的请求会严格按照顺序应用到Zookeeper中去。
原子性：要么全部成功、要么全部失败。
单一视图：无论连接哪个集群节点，看到的数据都是一样的。
可靠性：一旦请求成功，变更就会永久保存下来。
实时性：任何时候应用都能读到最新的状态。
2. 集群角色
传统分布式有Master/Slave概念，而Zookeeper引入了Leader、Follower和Observer三种角色。
Leader：提供读和写
Follower：提供读。Leader写数据时参与“过半写策略”。Leader出现故障时，参与“选举”。
Observer：提供读。不参与“选举”也不参与“过半写策略”，因此增加Observer能在不影响写性能的同时提高读性能。
3. ZAB协议
ZAB协议和Paxos不一样，它是一种崩溃可恢复的原子消息广播算法。它不算是一个通用的分布式一致性算法，侧重点是设计一个高可用的分布式数据主备系统。
ZAB将服务器数据状态变更以事务Proposal的形式广播给所有副本进程，这种主备模型架构保证了同一时刻集群只能有一个主进程来广播数据变更，这样可以很好地处理并发请求，并能保证顺序。
ZAB有两个基本模式，崩溃恢复和消息广播。当集群出现异常（网络中断、进程崩溃重启）时集群会进入恢复模式，开始选举Leader。选举产生新Leader后过半机器与Leader完成同步后集群就推出恢复模式，进入消息广播状态。
消息广播
原子广播协议类似2PC，不同之处在于移除了rollback逻辑，Follower要么正常反馈要么抛弃Leader服务器。并且只要过半的Follower已经成功反馈后就可以发送commit了。
广播过程中Leader服务器会为每个事务请求生成对应的propose，并为他们分配单调递增的唯一ID - ZXID。
ZXID作为事务编号，ZXID为64位数字，低32位为一个递增的计数器，每一个客户端的一个事务请求时Leader产生新的事务后该计数器都会加1， 高32位为Leader周期epoch编号，当新选举出一个Leader节点时Leader会取出本地日志中最大事务Proposal的ZXID解析出对应的epoch把该值加1作为新的epoch，将低32位从0开始生成新的ZXID
由于要保证因果关系，每个事务必须按照ZXID先后顺序进行排序处理。实现方式是follower节点将收到的事务请求加入到历史队列(history queue)中,并发送ack给ack给leader。
当follower收到commit请求时，会判断该事务的ZXID是不是比历史队列中的任何事务的ZXID都小，如果是则提交，如果不是则等待比它更小的事务的commit。
崩溃恢复
一旦Leader跪了或者出现网络分区导致Leader失去过半Follower，那么就立即进入崩溃恢复模式。崩溃恢复有几个阶段：选举、发现、数据同步
ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务
i: 选举
一般选出集群中拥有最大ZXID的节点。选举新Leader只要选举出拥有ZXID最大的机器出来即可。
ii: 发现
follower与潜在的新leader进行沟通，如果发现超过法定人数的follower同意，则潜在的新leader将epoch加1，进入新的leader周期。新的leader产生
iii: 数据同步
新Leader产生后，进入消息广播模式之前Leader需要确认所有Proposal是否已经被过半的机器提交了，提交了即完成了数据同步。
具体的，Leader会为每个Follower分配一个队列，将Follower上未提交的proposal逐个发给Follower并在其后跟一个Commit，表示该事务已经被提交。Follower同步完成后Leader将其放入真正可用的Follower列表中。
