该仓库翻译了zookeeper官方的一些文档,zookeeper版本为3.6.1，原文链接为https://zookeeper.apache.org/doc/r3.6.1/zookeeperAdmin.html
ZooKeeper是一个高性能的，为分布式应用提供协调功能的服务。它用一个简单的接口来暴露通用的服务-例如命名，配置管理，同步和分组服务，因此你不需要从头开始来编写这些服务。无需作重大修改，你就能使用zookeeper来实现一致性，集群管理，leader选举和节点在线协议。并且你可以基于zookeeper实现你自己特殊的需求
目录
ZooKeeper:一个分布式的,为分布式应用提供协调功能的服务
ZooKeeper是一个分布式的且开源的，为分布式应用提供协调功能的服务。它暴露了一套简单的原语，分布式应用能依赖它来实现更高级的服务，如同步，配置维护，分组和命名。它被设计成易于编程，并且使用了一个熟悉的文件系统的目录树结构的数据模型。它运行在java环境中，且它有java和c的绑定关系。
众所周知，协调服务是非常难以恢复正常的。协调服务特别容易产生诸如竞态条件和死锁的错误。zookeeper的动机就是不再让分布式应用承担从头开始实现协调服务的职责。
zookeeper的设计遵循简单的原则。zookeeper允许分布式的进程通过一个共享的有层次结构的命名空间来互相协调，这个命名空间被组织成一个标准的文件系统。这个命名空间包含在zookeeper术语中被称为znode的数据寄存器，且这些znode与文件和目录类似。不像一个典型的文件系统被设计用作存储，zookeeper的数据被保存在内存中，这意味着zookeeper能够实现高吞吐低延迟。
Zookeeper的实现非常重视高性能，高可用，严格的顺序访问。在zookeeper的性能层面，它能被使用在大型的分布式系统中。在可靠性方面，zookeeper能够避免单点故障。严格的顺序意味着复杂的同步能够在客户端被实现。
zookeeper基于复制。与zookeeper协调的分布式进程一样，zookeeper自己通过一组被称之为ensemble的主机来实现复制。
组成zookeeper服务的每个服务器必须了解其他服务器的状态。这些服务器在内存中维护着其他服务器的状态，除此之外，在一个持久化存储中也维护了一个事物日志和快照。只要大多数服务器是可用的，zookeeper服务就会是可用的。
每个客户端连接到一个zookeeper服务器。客户端维护了一个tcp连接，通过这个连接，客户端发送请求，获取响应，获取监听事件和发送心跳。如果连接服务器的tcp连接中断，这个客户端会连接到另一个不同的服务器。
zookeeper是有序的。zookeeper使用了一个数字来记录每一次更新操作，这个数字反映了所有zookeeper事物的顺序。后面的操作能够使用这个顺序来实现更高级的抽象，例如同步。
zookeeper是快速的。在以读操作为主的工作任务中，它特别快。zookeeper应用运行在成千上万的机器中，且这些机器的读操作比写操作更多，大约10:1的比例，zookeeper的性能表现最好。
zookeeper提供的命名空间和标准的文件系统非常像。命名空间由一系列被斜线分隔的路径组成。zookeeper的命名空间中的每个节点用一个路径标识。
zookeeper具有层级结构的命名空间
和标准的文件系统不一样的是，zookeeper的命名空间中的每个节点可以存储和该节点及其子节点相关的数据。这就像拥有一个允许文件也是目录的文件系统一样。（zookeeper被设计用来存储协调数据：状态信息，配置，寻址信息等，所以每个节点存储的数据通常来说是轻量的，在b（字节）到kb（千字节）的范围。）我们把正在谈论的zookeeper数据节点叫做znode。
znode维护了一个状态结构，它包含用于记录数据变更，访问控制列表变更和时间戳的版本号，通过这个状态结构可以实现缓存校验和协调更新。每当一个znode的数据变更了,这个版本号就会增大。例如，客户端无论何时检索数据，客户端也会收到数据的版本号。
命名空间里的每个znode存储的数据被原子性地读取和写入。读取操作获取和一个znode相关的所有字节数据，写入操作替换所有数据。每一个节点有一个限定谁能做什么操作的访问控制列表（ACL）。
zookeeper也有临时节点的概念。只要被znode创建的会话是有效的，这个znode就存在。当这个会话结束，这个znode就被删除。
zookeeper支持监听的概念。客户端可以在一个znode节点上设置一个监听。当这个znode节点变更时，这个监听会被触发和移除。当一个监听被触发时，这个客户端会接收到一个数据包，这个数据包会告知客户端这个znode节点发生了变化。如果客户端和一个zookeeper服务器之间的连接断开了，这个客户端会接收到一个本地通知。
3.6.0版本的新特性：客户端也可以在一个znode节点上设置永久的循环监听,当这些监听被触发时，这些监听不会被移除。在被注册的znode节点和任何递归的子znode节点，也是如此。
zookeeper是非常快速和简单的。因为它的目标，是作为更复杂服务的构建基础，例如同步，所以它提供了一套保障机制。这些保障机制是：
-
顺序一致性 - 来自一个客户端的多个变更会以它们被发送的顺序修改。
-
原子性 - 多个更新要么全部成功要么全部失败。不会存在部分更新成功的情况。
-
单系统镜像 - 不管一个客户端连接到哪个zookeeper服务器，这个客户端都会看见相同的zookeeper服务视图。一个客户端绝对不会看见一个更老旧的系统视图，即使这个客户端将故障转移到了一个不同的但保有相同会话的服务器。
-
可靠性 - 一旦一个变更已经被应用，这个变更就会从那个时间开始持久化，直到一个客户端重写这个变更。
-
时效性 - 在某个时间范围内，zookeeper系统的客户端视图被确保是最新的。
zookeeper的设计目标之一是提供一个非常简单的编程接口。所以，它只支持这些操作：
节点创建：在这颗目录树的一个位置，创建一个节点
-
节点删除：删除一个节点
-
节点存在性判断：判断一个节点在一个位置是否存在
-
获取节点数据：从一个节点读取数据
-
设置节点数据：将数据写入一个节点
-
获取子节点：检索一个节点的子节点列表
-
同步：等待要被传播的数据
Zookeeper组件展示了zookeeper服务的高级组件。因为请求处理器处理请求时会发生异常，所以每个组成zookeeper服务的服务器会复制它自己的副本。
这个复制数据库是一个包含全部数据树的内存数据库。变更会被记录到磁盘，用作恢复，并且在写入操作被同步到内存数据库之前，写入操作会被序列化到磁盘。
每个zookeeper服务器服务于客户端。客户端准确地连接到一个服务器，用于提交请求。数据读取请求，由每个服务器的本地副本数据库提供服务。zookeeper服务状态的变更请求，以及写入请求，被一个一致性协议处理。
作为一致性协议的一部分，所有来自客户端的数据写入请求被转发到一个唯一的服务器，这个服务器被称作leader。zookeeper服务器的其他服务器被称作followers，接收来自leader的消息提议，并且就消息传递达成一致。这个消息层关心故障leader的替换以及leader和follower间的同步。
Zookeeper使用了一个自定义的原子消息协议。因为消息层是原子性的，所以zookeeper能够保证这些本地副本从来不会不一致。当leader接收到一个写入请求，在这个写入操作将要被保存时leader会计算zookeeper的系统状态,并且会将这个写入操作放入到一个捕获这个新状态的事务中。