一、何为Zookeeper?
ZooKeeper 是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
二、Zookeeper可以保证分布式哪些特性？
1.顺序一致性
从同一个客户端发起的事务请求，最终将会严格地按照其发起顺序被应用到 ZooKeeper 中去
2.原子性
所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群所有机器都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况
3.单一视图
无论客户端连接的是哪个 ZooKeeper 服务器，其看到的服务端数据模型都是一致的。可靠性 一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。
4.实时性
通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是， ZooKeeper 仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。
三、 ZooKeeper 的设计目标
ZooKeeper 致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力（主要是写操作的严格顺序性）的分布式协调服务。高性能使得 ZooKeeper 能够应用于那些对系统吞叶有明确要求的大型分布式系统中，高可用使得分布式的单点问题得到了很好的解决，而严格的顺序访问控制使得客户端能够基于 ZooKeeper 实现一些复杂的同步原语。下面我们来具体看一下 ZooKeeper 的四个设计目标。（后面章节会详细介绍）
1. 简单的数据模型
ZooKeeper 使得分布式程序能够通过一个共享的、树型结构的名字空间来进行相互协调。
2. 可以构建集群
一个 ZooKeeper 集群通常由一组机器组成，一般 3～5 台机器就可以组成一个可用的 ZooKeeper 集群了，
3.顺序访问
对于来自客户端的每个更新请求，ZooKeeper 都会分配一个全局唯一的递增编号，这个编号反映了所有事务操作的先后顺序，应用程序可以使用 ZooKeeper 的这个特性来实现更高层次的同步原语。
4.高性能
由于 ZooKeeper 将全量数据存储在内存中，并直接服务于客户端的所有非事务请求，因此它尤其适用于以读操作为主的应用场景。作者曾经以 3台 3.4.3 版本的 ZooKeeper 服务器组成集群进行性能压测，100%读请求的场景下压测结果是 12~13W 的 QPS。
四、 ZooKeeper 的集群角色
通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式就是 Master/Slave 模式（主备模式）。
在这种模式中，我们把能够处理所有写操作的机器称为 Master 机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器称为 Slave 机器。 而在 ZooKeeper 中，这些概念被颠覆了。它没有沿用传统的 Master/Slave 概念，而是引入了 Leader、Follower 和 Observer 三种角色。
ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台被称为"Leader"的机器，Leader 服务器为客户端提供读和写服务。除 Leader 外，其他机器包括 Follower 和 Observer。Follower 和 Observer 都能够提供读服务，唯一的区别在于，Observer 机器不参与 Leader 选举过程，也不参与写操作的"过半写成功"策略，因此 Observer 可以在不影响写性能的情况下提升集群的读性能。
五、 ZooKeeper 的 ZAB协议
ZooKeeper 并没有完全采用 Paxos 算法，而是使用了一种称为 ZooKeeper Atomic Broadcast（ZAB，ZooKeeper 原子消息广播协议）的协议作为其数据一致性的核心算法。 ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。ZAB协议的开发设计人员在协议设计之初并没有要求其具有很好的扩展性，最初只是为雅虎公司内部那些高吞吐量、低延迟、健壮、简单的分布式系统场景设计的。在 ZooKeeper 的官方文档中也指出，ZAB 协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 ZooKeeper 设计的崩溃可恢复的原子消息广播算法。后面文章会详解
ZAB协议包含两种基本模式，分别是：
（1）崩溃恢复之数据恢复
（2）消息广播之原子广播
