是一个分布式应用程序协调服务，是Google的Chubby一个开源的实现，是众多开源分布式应用的核心组件之一。架构图如下所示：
它为分布式应用提供配置维护、域名服务、分布式同步、分布式锁、服务注册等服务。ZooKeeper具备以下几个特性。
简单易用
以分布式方式协调各个应用程序，它提供一个共享的分级的命名空间，这个命名空间类似于一个标准的Linux文件系统。命名空间由称之为znode的数据注册者组成，它的语法与文件和目录的相似。不像为存储而设计的典型文件系统，ZooKeeper数据是保存在内存中，这样使得ZooKeeper能够实现高吞吐和低延迟。具体数据模型，见下图。
ZooKeeper分级命名空间
重复性
如ZooKeeper协助的分布式处理一样，它本身就是在一个被称为ensemble的集合主机之中进行重复的。那些组成ZooKeeper服务的服务器（Servers）必须彼此了解。就是这些服务器维持着内存的状态印象，伴随着事务日志和持久化存储的快照（Snapshots）。只要主要的服务器有效存在，ZooKeeper服务就会提供可能的服务。当客户端连接到一个单一的ZooKeeper服务器时，客户端维持着一个TCP连接。通过这个TCP连接，客户端可以发送请求，获得响应答复，得到观察者监听事件，发送心态状态信息。如果这个TCP连接中断，客户端将连接到不同的机器。
有序性
以一个数字标记任何一次更新，这个数字反应了所有ZooKeeper事务的有序性。随后，操作能够使用这个有序性实现更高级的抽象，比如同步原生态操作。
性能高效
在于只读的工作量中，ZooKeeper是特别高效的。ZooKeeper应用程序可以运行在成千上万的机器上，当一般的读大于写的操作时，ZooKeeper表现出最佳的性能，尤其是读写比例达到10:1.下面一个性能测试报告，见下图。
可靠性
支持失败容错，ZooKeeper集群是由一个leader和剩余的follower组成，一旦leader失效，follower会根据leader选举算法选举出新的leader。为了呈现ZooKeeper的可靠性，我们运行一个有7个节点组成的ZooKeeper服务。测试结果图如下所示：
从上图表可以知道，如果follower失效和快速恢复时，ZooKeeper能够维持一个高吞吐量。更重要的是，leader选择算法允许系统进快地复原，以便防止吞吐量致命地下降。从上图可知，ZooKeeper至少要200ms推举出一个新的leader。随着follower恢复正常状态，ZooKeeper不断提高它处理请求的能力。下图是应用程序进程、客户端库（Client Library）与ZooKeeper Ensemble的交互模型。
2.1 Zookeeper使命
为协调分布式系统的实现了协调工作。下面让我们来看ZooKeeper为那些系统提供了核心服务。
Apache HBase
是一个以Hadoop为基石的海量数据列存储系统。在HBase系统中，ZooKeeper用于选择一个集群的master，保持跟踪有效的主机服务器，维护集群的元数据（metadata）。
2. Apache Kafka
是一个发布/订阅的消息系统。它使用ZooKeeper侦测崩溃的节点，实现topic发现，为topic维护生产和消耗状态。
Apache Solr
是一个企业级检索平台服务框架。它的分布式形式称为SolrCloud。它使用ZooKeeper来存储有关集群的元数据以及协调更新这些元数据。
总而言之，ZooKeeper可以实现下面几类服务。
l Master election：master节点给有效的worker节点分配任务。
l Crash detection：master节点必须侦测worker节点有效性，包括是节点down机，无法连接等问题。
l Group membership management：maste节点必须能够发现那些worker节点能够有效执行任务。
l Metadata management ：master和worker节点必须具备存储分配的任务和执行的状态，并且保证此方法的可靠性。
