zookeeper是一个分布式服务器群，共同为群集应用程序提供可靠的协调和同步服务。
允许，名称"Zookeeper"似乎起初是一个奇怪的选择，但是当我们了解它为HBase集群所做的操作时，我们可以看到它后面的逻辑。
当我们建立和调试分布式应用程序时，"这是一个动物园，所以你应该把zookeeper放在你的团队上。

HBase集群可以庞大并协调MasterServers，Revionservers和客户端的操作可以是一个令人生畏的任务，但这就是Zookeeper进入图片的地方。
如在HBASE中，Zookeeper集群通常在低成本商品X86服务器上运行。

每个单独的x86服务器上运行的单一动物园管理员软件处理(下文中被称为一个动物园管理员服务器)，与由合奏作为领队和服务器的其余部分选出一个动物园管理员服务器是跟随者。
Zookeeper合奏受到多数法定法的原则的管辖。

测试和开发目的支持带有一个Zookeeper服务器的配置，但如果我们想要一个可容忍服务器故障的可靠集群，则需要部署至少三个zookeeper服务器以实现多数法定值。

那么，你需要多少个zookeeper服务器？
五是建议生产使用的最低限度，但我们真的不想使用最低限度。
当我们决定计划Zookeeper合奏时，请按照此简单的公式：2F + 1 = n其中f是我们可以在zookeeper群集中接受的故障数，n是我们必须部署的zookeeper服务器的总数。

建议使用五个，因为可以关闭一个服务器进行维护，但ZooKeeper群集仍可容忍一个服务器故障。

zookeeper提供与znodes调用的协调和同步，这些znodes作为目录树呈现，类似于我们在Unix文件系统中看到的文件路径名称。
Znodes do存储数据，但默认情况下，不得不说明 - 目前小于1 MB。

这里的想法是，Zookeeper在内存中存储Znodes，这些基于内存的Znodes提供了快速的客户端访问分布式应用程序所需的协调，状态和其他重要函数，如hbase等。
zookeeper在整个集合上复制znodes，因此如果服务器失败，只要仍然仍在运行，znode数据仍然可用。

另一个主要的Zookeeper概念涉及如何处理Znode读取(与写入)。
任何zookeeper服务器都可以处理来自客户端的读数，包括领导者，但只有领导者发出原子znode写道 - 写入完全成功或者完全失败的写入。

当Znode写请求到达领导节点时，领导者向跟随者节点广播写入请求，然后等待大多数粉丝以确认Znode写入完成。
在确认之后，领导者发出Znode写自己，然后向客户端报告成功的完成状态。

Znodes提供了一些非常强大的保证。
当ZookeEper客户端(例如HBase Regionserver)写入或者读取Znode时，操作是原子的。
它完全成功或者完全失败 - 没有部分读取或者写入。

没有其他竞争客户端可能导致读取或者写入操作失败。
此外，Znode具有与安全性相关联的访问控制列表(ACL)，并且当它在变化时支持版本，时间戳和通知客户端。

zookeeper在整个集合上复制znodes，因此如果服务器失败，只要仍然仍在运行，znode数据仍然可用。
这意味着写入来自任何ZooKeeper服务器的任何Znode必须在整体上传播。
ZooKeeper领导者管理此操作。

这种Znode写入方法可能导致追随者落后于领导者的短时间。
Zookeeper通过提供同步命令来解决这个潜在问题。
无法容忍ZooKeeper群集中此临时缺乏同步的客户端可能决定在读取Znodes之前发出同步命令。