Zookeeper 分布式服务框架是 Apache Hadoop 的一个子项目，主要用来解决分布式应用中经常遇到的一些数据管理问题，如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。
简单来说，Zookeeper = 文件系统+ 通知机制。Zookeeper 提供了以下服务：
1）文件系统
Zookeeper 维护一个类似文件系统的数据结构，结果如图 6-9 所示。
每一个子目录项，如 NameService 都被称作 znode，和文件系统一样，能够自由地增加、删除 znode，在一个 znode 下增加、删除子 znode，唯一的不同在于 znode 是可以存储数据的。有四种类型的 znode：
（1） PERSISTENT，持久化目录节点：
客户端与 Zookeeper 断开连接后，该节点依旧存在。
（2） PERSISTENT_SEQUENTIAL，持久化顺序编号目录节点
客户端与 Zookeeper 断开连接后，该节点依旧存在，只是 Zookeeper 给该节点名称进行顺序编号。
（3） EPHEMERAL，临时目录节点：
客户端与 Zookeeper 断开连接后，该节点被删除。
（4） EPHEMERAL_SEQUENTIAL，临时顺序编号目录节点：
客户端与 Zookeeper 断开连接后，该节点被删除，只是 Zookeeper 给该节点名称进行顺序编号。
2）通知机制
客户端注册监听它关心的目录节点，目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，Zookeeper 会通知客户端。
Zookeeper 能提供如下服务：
（1） 命名服务。
在 Zookeeper 的文件系统里创建一个目录，即有唯一的 path。在使用 tborg 无法确定上游程序的部署机器时即可与下游程序约定好 path，通过 path 即能完成互相探索。
（2） 配置服务。
程序是需要配置的，如果程序分散部署在多台机器上，想要逐个改变配置则变得困难。现在把这些配置全部放到 Zookeeper 上，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。
（3） 集群管理。
● 是否有机器退出。
所有机器约定在父目录 GroupMembers 下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器宕机，该机器与Zookeeper 的连接断开， 其所创建的临时目录节点被删除，所有其他机器都收到某个兄弟目录被删除的通知，于是，所有机器都知道了。新机器加入也是类似，所有机器收到新兄弟目录加入的通知，highcount 又有了。
● 选举master。
所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master 即可。
（4） 分布式锁。
锁服务可以分为两类：一类是保持独占；另一类是控制时序。
对于第一类，将 Zookeeper 上的一个 znode 看作一把锁，通过 createznode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点释放出锁。
对于第二类，/distribute_lock 节点已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，与选master 类似，编号最小的获得锁，用完删除， 依次类推。
（5） 队列管理。
如下为两种类型的队列：
● 同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
● 队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否为要求的 数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号， 出列按编号。
终于知道能用 Zookeeper 做什么了，总是想了解 Zookeeper 是如何做到这一点的，单点维护一个文件系统没有什么难度，可是如果一个集群维护一个文件系统保持数据的一致性就非常困难了。
3） 分布式与数据复制
Zookeeper 作为一个集群提供一致的数据服务，因此它要在所有机器间做数据复制。数据复制的好处如下：
（1） 容错。一个节点出错，不至于让整个系统停止工作，别的节点可以接管它的工作。
（2） 提高系统的扩展能力 。把负载分布到多个节点上，或者增加节点来提高系统的负载能力。
（3） 提高性能。让客户端本地访问就近的节点，提高用户访问速度。从客户端读写访问的透明度来看，数据复制集群系统分为下面两种：
● 写主（Write Master）：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离。
● 写任意（Write Any）：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。
对 Zookeeper 来说，它采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好。而随着机器的增多写吞吐能力肯定下降（这也是它建立 observer 的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。
关注的重点还是在如何保证数据在集群所有机器的一致性，这就涉及Paxos 算法。
4） 数据一致性与 Paxos 算法
在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么它们最后能得到一个一致的状态。
Paxos 算法就是保证每个节点执行相同的操作序列。master 维护一个全局写队列，所有写操作都必须放入这个队列并进行编号，那么无论写多少个节点， 只要写操作是按编号来，就能保证一致性。可是如果 master 宕机了呢。
Paxos 算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一轮投票，就这样，在一次又一次的投票中，所有写操作都被严格编号排序。编号严格递增，当一个节点接收了一个编号为 100 的写操作，之后又接收到编号为 99 的写操作（因为网络延迟等不可预见原因），它马上能意识到自己的数据不一致了，自动停止对外服务并重启同步过程。任何一个节点宕机都不会影响整个集群的数据一致性（总 2n+1 台，除非挂掉大于 n 台）。
系统模型如图 6-10 所示：
