原文地址：ZooKeeper: A Distributed Coordination Service for Distributed Applications ZooKeeper是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务——如同步、配置维护、群组和命名管理
原文地址：ZooKeeper: A Distributed Coordination Service for Distributed Applications
ZooKeeper是一个用于分布式应用程序的分布式开源协调服务。它使用一组简单的操作原语，使得分布式应用可以实现更高层次的服务——如同步、配置维护、群组和命名管理等。它以易于编程为基本设计理念，并使用了一个类似于文件系统目录结构风格的数据模型。ZooKeeper服务运行于Java环境中并可以在Java和C中使用。
众所周知，协调服务很难达到正确，尤其会出现竞争条件或死锁等问题。ZooKeeper设计初衷是为了缓解分布式应用从设计到实现中协调服务的问题。
ZooKeeper的实现简单。它使得分布式进程与其他进程通过一个共享的层级的命名空间（类似于标准文件系统目录的）来进行协调。命名空间由被称为znode的数据注册表（类似文件系统中的文件和目录）组成。而与面向数据存储的文件系统不同的是， ZooKeeper将数据保持在内存中，这意味着ZooKeeper有更大的吞吐量和更小的延时。
ZooKeeper是冗余的。就像它所协调的分布式进程一样，ZooKeeper自身实现了一些主机间复制并成为一个集群整体。
组成ZooKeeper服务的这些服务器必须相互连通。它们通过事务日志和持久化存储上的快照来维护一个状态的内存镜像。只要大多数服务可用，ZooKeeper服务就可用。
客户端连接到一个ZooKeeper服务器，它维持一个发送请求、接受应答、获取监听时间并发送心跳信息的TCP连接。如果这个连接中断，客户端会连到其他的服务器。
ZooKeeper是有序的。Zookeeper会以反映ZooKeeper全局事务序列的数值标记每次更新操作，后续的操作可以使用这个序列来实现高层的抽象，例如同步原语。
ZooLeeper是高效的。尤其是在读写比很大的情况下。ZooKeeper的应用运行在数千台服务器上，它的应用表现会在这种读多写少的场景下表现良好（读写比大约会在10：1）。
ZooKeeper提供的命名空间和标准文件系统很像。一个名字是以(/)分割路径元素组成的序列。每个Zookeeper明明空间中的节点都通过路径被识别。
和标准文件系统不同的是，每一个ZooKeeper命名空间中的节点和它们的子节点一样拥有数据，这就像一个文件也可以作为目录的文件系统。（ZooKeeper被设计用于存储协调数据：状态信息、配置、位置信息等。所以每个节点存储的数据通常很小，大约在字节到千字节级别）。我们称ZooKeeper的数据节点为znode。
Znode维护一个统计结构（包含了数据改变的版本号，访问控制列表改变和时间戳）来允许缓存验证和协调更新。每次znode数据改变，版本号会递增。例如，当客户但获取数据时它也会接受数据的版本信息。
命名空间中每个znode存储的数据的读写都是原子操作。读操作会得到一个znode相关的所有数据字节，写操作替换znode相关的所有数据。每一个节点都有一个访问控制列表来限制谁有权限能做什么。
ZooKeeper中也有临时节点的概念，这些节点会在创建这些节点的会话有效时存在，当会话结束后被删除。临时节点在你想要实现一些特定操作时（[tdb]原文未补全）时非常有用。
Zookeeper支持监听(watches)的概念。客户端可以在znode上设置一个监听，一个监听可以在znode被改变后触发和删除。当一个监听触发后，客户端接受一个通知znode改变的数据包。并且如果客户端和ZooKeeper中一个服务器之前的连接出现故障，客户端会收到一个本地通知，这些可以用于一些可高可用性的服务实现（[tdb]此处原文未补全）。
ZooKeeper非常简单高效。虽然它的设计目标是建立的更复杂的服务(例如同步)的基础，它提供了一些保证机制：
顺序一致：通过客户端的更新会以他们发出操作的顺序来应用。
原子性：无论更新是否成功，不存在部分更新。
单一系统镜像：无论一个客户端连到哪一个服务器，会看到服务的相同视图。
可靠性：一旦一个更新被应用，这次更新会从这个时刻开始持久化直到下次客户端覆盖这次更新的内容。
及时性：系统的客户端视图保证在一个确定时候限度内是最新的。
更多信息可以参考官方文档、白皮书。（[tdb]）
ZooKeeper的设计目标之一是提供一个非常简单的编程接口，所以它只提供了下面的操作：
create – creates a node at a location in the tree
delete – deletes a node
exists – tests if a node exists at a location
get data – reads the data from a node
set data – writes data to a node
get children – retrieves a list of children of a node
sync – waits for data to be propagated
关于这些内容的更多讨论，以及使用它们如何实现高层的操作，请参考官方文档。（[tdb]）
Zookeeper组件展示了ZooKeeper服务的高层组件。除了请求处理器之外, 组成zookeeper服务的每个server都会在本地备份每一个组件的拷贝。
这个被复制的数据库是一个包含内存全部数据的树型内存数据库。更新操作会写入磁盘并用于恢复，写入操作会在应用到内存数据库之前序列化到磁盘中。
每一个ZooKeeper数据库都可以用于客户端的连接，客户端连接到一个服务器上去提交请求。读请求可以在每一个服务器数据库的复制片中获取，而改变服务状态的请求和写请求则通过一个一致性协议进行。
作为一致性协议的一部分，所有来自客户端的写请求会流入一个单一的服务器——称为领导者（leader），剩余的ZooKeeper服务器称为追随者（followers），它们从领导者上接收消息提议并对消息传递达成一致性意见。消息传递层会（the messaging layer）处理当领导者故障时选举新的领导者，以及追随者和领导者之前的同步。
ZooKeeper使用一个定制的原子消息传递协议，由于消息传递层是原子操作，ZooKeeper能保证本地复制篇不会产生偏离。当领导者接收一个读请求时，它会计算系统的状态到应用写入被应用的时刻，并将系统状态转换到新的事务状态。
Zookeeper的编程接口非常简单。然而使用这些API，你可以实现高层的操作（例如同步原语、组成员、所有权等）。更多分布式应用的操作可以参考白皮书和视频资料（[tdb]）。
ZooKeeper被设计初衷是高性能。但真的如此么？Yahoo研究中心的ZooKeeper开发团队证实了ZooKeeper的高性能，特别是在读多写少的应用中（见下图），因为写操作需要在所有ZooKeeper服务器间同步状态。（读多写少是协调服务的典型应用情况）
图为两个2GHz至强处理器和两个SATA 15K RPM驱动器的服务器上ZooKeeper 3.2运行时的吞吐量。一个磁盘驱动器作为ZooKeeper日志的专用设备。快照写入到操作系统所在的磁盘驱动器。读写操作都操作1KB的数据。图 中“Servers”指的是ZooKeeper服务的大小，即组成服务的服务器个数。客户端通过大约30个其他服务器来模拟。ZooKeeper集群配置不允许客户端连接到领导者。
提示：3.2版的r/w性能是3.1版的2倍。
上面基准测试也表明ZooKeeper是可靠的。下图显示了ZooKeeper在各种失败情况下的反应。图中标记的各个事件是：
1．追随者失败和恢复
2．另一个追随者失败和恢复
3．领导者失败
4．两个追随者失败和恢复
5．另一个领导者失败
为展示当节点失败发生时系统的行为，我们在一个由7台机器组成的ZooKeeper服务上运行和上节一样的基准测试，但这次我们将写操作的百分比固定为30%，这是预期负载比例的保守估计。
此图有几处值得仔细观察。首先，如果追随者失败后快速恢复，则ZooKeeper可以维持高吞吐率。但更重要的是，领导者的选举算法让系统可以很快地恢复，以避免吞吐率有实质性下降。据我们观察，ZooKeeper集群在选举一个新的领导者的时间小于200ms。第三，一旦追随者恢复并且开始处理请求，ZooKeeper可以恢复高吞吐率。
?
ZooKeeper已经在很多工业应用中被成功使用。Yahoo!在Yahoo! Message Broker中使用ZooKeeper作为协调和故障恢复服务。Yahoo! Message Broker是一个高度扩展的发布-订阅系统（目前主流的kfaka也使用ZooKeeper），管理着成千上万个需要拷贝和数据传递的话题。Yahoo!的很多广告系统也使用ZooKeeper来实现可靠服务。
我们鼓励用户和开发者加入社区。更多信息请看Apache的ZooKeeper项目。
原文地址：【译】ZooKeeper：一个用于分布式应用的分布式协调服务, 感谢原作者分享。
