是一个高可靠、高可用、高性能的分布式一致系统，核心为ZAB协议。
zookeeper一致性协议
zookeeper实现数据一致性的核心是ZAB协议（Zookeeper原子消息广播协议）。该协议需要做到以下几点：
（1）集群在半数以下节点宕机的情况下，能正常对外提供服务；
（2）客户端的写请求全部转交给leader来处理，leader需确保写变更能实时同步给所有follower及observer；
（3）leader宕机或整个集群重启时，需要确保那些已经在leader服务器上提交的事务最终被所有服务器都提交，确保丢弃那些只在leader服务器上被提出的事务，并保证集群能快速恢复到故障前的状态。
zookeeper设计特点
高性能：全部数据内存存储，即存储的数据量是有限的，受限于所在宿主机的内存的大小
高可用：只要可用机器数在一半以上就是可用的。
一致性：ZAB协议保证，事务要么完成，要么未完成，未有中间状态。
ZAB协议与paxos对比
共同点：
leader向所有的followers提议。
leader在收到一定数目的followers的ack之后，才会commit。
提议中包含epoch，类似于paxos的ballot number。
不同点：
一个有状态的机器（zab协议）是用来处理一系列的请求。一个有状态的机器复制系统，是一个clientserver系统，每个状态机器的复制请求都会按照client请求的顺序进行执行。
在主备份系统中（paxos协议），一致性是delta状态的一致性。由主备份产生并发送给followers。
ZAB协议：
协议定义
leader followers：有一个唯一的leader，若干个followers，leader+followers满足奇数个。leader角色负责接受所有的从clients或者从follower以副本形式发过来的变更状态。读请求则在所有的followers与leader之间进行负载均衡。
事务：所有的状态变更由leader广播给所有的followers
e- leader的标志。epoch是一个整数，在一个leader开始领导的时候产生，并且应该比前面的leader的epoch都大
c-leader产生的一个顺序数字，从0开始并且递增。与epoch一起用来标识从client过来的状态变化
F.history-followers的历史队列。用来有顺序的提交过来事务顺序。
ZAB Implementation
clients可以从zk nodes的任何一个server读数据；
clients的写状态变更可以发送到任何一个server，这个状态的变更被转发到leader节点。zk 用一个改良的二阶段提交协议将复制的事务发送给followers。当leader收到client的变更请求，leader会产生一个带有sequencenumber以及epoch的事务发送给所有的followers。一个follower将事务添加到历史队列中并发送ack给leader。当leader收到法定个数的ack，就会发送commit请求。一个follower接收COMMIT请求，并提交事务；除非sequencenumber比历史队列中的sequencenumber大？。在提交之前，等待收到所有的比它早的事务。
如果leader崩溃，所有的nodes将拒绝服务，并会执行恢复协议来达成一致状态，选举一个新的leader来广播状态变更。
为了选择leader，node必须获取一定数目nodes的支持。
node的生命周期：每个node在一定时间内会执行协议的迭代。在任何时间点，一个进程可能放弃当前的迭代，并开始一个新的阶段0
ZAB协议生命周期
阶段0-预期leader选举
阶段1-发现
阶段2-同步
阶段3-广播
阶段1 和 2 对于达成一致状态，特别是从崩溃中恢复至关重要
阶段1-发现 在这个阶段，followers对他们预期的leader进行通信，leader 收集followers接收的最近最新的事务信息。这个阶段的目的是在一定树木中发现接受的事务的最新sequence，建立一个新的epoch，让以前的leaders不能提交新的提议。因为一定数目的followers有前面的leader发送的已经接受的所有的变更-那么至少有一个follower在他的历史队列中有所有已经接受的变更，这就意味着新的leader也会拥有他们。
阶段2-同步 同步阶段包含协议的恢复阶段，将在发现阶段更新的历史事务在集群间同步所有的备份。leader与followers进行通信，提议事务。followers确认提议。当leader收到一定数目的acks，leader就会发起一个commit 信息。在那个时候，leader已经建立了，已经是非预期了。
阶段3-广播 如果没有崩溃，集群将会永远在这个阶段，当client发起一个写请求的时候，在集群之间进行广播事务。为了发现失败，zab 在leader与followers之间有周期性的心跳。如果在给定时间内leader未收到一定数目的心跳，它将会放弃他的领导地位，并开始选举阶段0.如果follower未在一定时间内收到心跳，也会发起选举leader。
附录
https://distributedalgorithm.wordpress.com/2015/06/20/architecture-of-zab-zookeeper-atomic-broadcast-protocol/
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab1.0
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Zab+vs.+Paxos