Zookeeper：为分布式引用提供了一个高效可靠的分布式协调服务。实现依赖于ZAB协议，实现了一种主备模式的架构来保持集群中数据的一致性。Zookeeper使得分布式引用可以通过一个共享的树形结构的命名空间实现协调。Zookeeper将所以普的数据存储在内存中。Zookeeper集群中的任何一台机器都可以响应客户端的读操作，且全量数据存在与内存中，因此Zookeeper更适合以读操作为主的引用场景。集群中包括三种角色：leader、follower、observer。其中leader是通过选举确定的一台机器，为客户端提供读写功能，follower与observer提供读功能，不同的是observer不参与选举，也不参与过半写成功策略，因此observer可以在不影响写性能的前提下提升集群的读性能。Zookeeper集群节点的数量为奇数个。Zookeeper的节点分为临时节点、持久节点、顺序节点，每个节点有一个stat结构。最重要的功能就是watcher功能。开元客户端也有：zkclient、curator
ZAB协议：是为Zookeeper专门设计的一种支持崩溃恢复的消息广播协议。ZAB协议只允许有一个主进程接受客户事务请求并处理，即leader。当leader收到请求后，将请求事务转化为事务proposal，由于leader会为每一个follower创建一个队列，将该事务放入响应队列，保证事务的顺序性，之后会在队列中顺序向其他节点广播该提案，follower收到会将其以事务的形式写入到本地日志中，并向leader发送反馈ack。leader会等待其他follower的回复，当收到一半以上的follower响应时，leader会向其他节点发送commit消息，同时leader提交该提案。
ZAB有两种模式：故障恢复模式以及消息广播。
当系统启动或者leader服务器出现故障等现象时，进入故障恢复模式。将会开启新的一轮选举。选举产生的leader会与过半的follower进行同步，使数据一致，当同步结束后，退出恢复模式，进入消息广播模式。当一台遵从ZAB协议的服务器启动后，如果检测到有leader在广播消息，会自动进入恢复模式，当其完成与leader的同步以后，进入消息广播模式。如果集群中的非leader节点收到客户端请求，非leader节点会先将请求发送到leader服务器。
故障恢复如下：
ZAB协议需要保证已经被leader提交的事务最终被所有的机器提交；
ZAB协议需要保证丢弃那些只在leader上提出的事务；
为了保证以上两点，选举时如果选择ZXID最大的节点就可以解决上述的问题。数据同步是为每一个follower创建一个队列，leader将各个follower没有提交的事务写入各个队列，并发送给各个follower。follower将事务同步后leader将其加入真正可用的follower列表。
leader重新选举的条件：leader宕机或发生故障，集群中少于一般的节点与当前leader保持连接。
