ZooKeeper详解之一

ZooKeeper介绍

ZooKeeper 是分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序可以基于这些原语来实现更高级别的同步、配置维护以及组和命名服务。它被设计为易于编程，并使用以熟悉的文件系统目录树结构为样式的数据模型。它在 Java 中运行，并且具有 Java 和 C 的绑定。

设计目标

ZooKeeper 很简单。ZooKeeper 允许分布式进程通过共享的分层命名空间相互协调，该命名空间的组织类似于标准文件系统。命名空间由数据寄存器组成——在 ZooKeeper 中称为 znodes——这些类似于文件和目录。与典型的为存储而设计的文件系统不同，ZooKeeper 数据保存在内存中，这意味着 ZooKeeper 可以实现高吞吐量和低延迟。

ZooKeeper 实现非常重视高性能、高可用、严格有序的访问。ZooKeeper 的性能方面意味着它可以用于大型分布式系统。可靠性方面使其不会成为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。

ZooKeeper 被复制。就像它协调的分布式进程一样，ZooKeeper 本身旨在通过一组称为集合的主机进行复制。

组成 ZooKeeper 服务的服务器必须相互了解。它们维护内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper 服务就可用。

客户端连接到单个 ZooKeeper 服务器。客户端维护一个 TCP 连接，通过它发送请求、获取响应、获取监视事件和发送心跳。如果与服务器的 TCP 连接中断，客户端将连接到不同的服务器。

ZooKeeper 已订购。ZooKeeper 用反映所有 ZooKeeper 事务顺序的数字标记每个更新。后续操作可以使用顺序来实现更高级别的抽象，例如同步原语。

ZooKeeper 速度很快。它在“读取主导”工作负载中特别快。ZooKeeper 应用程序在数千台机器上运行，它在读取比写入更常见的情况下表现最佳，比率约为 10:1。

数据模型和分层命名空间

ZooKeeper 提供的命名空间很像标准文件系统的命名空间。名称是由斜杠 (/) 分隔的一系列路径元素。ZooKeeper 命名空间中的每个节点都由路径标识。
ZooKeeper 的分层命名空间:

有条件的更新和监视

zookeeper支持的watch监控和观察。客户端可以在 znode 上设置监视。当 znode 发生变化时，会触发并移除 watch。当 watch 被触发时，客户端会收到一个数据包，说 znode 已经改变了。如果客户端和 ZooKeeper 服务器之一之间的连接中断，客户端将收到本地通知。

3.6.0 中的新功能：客户端还可以在 znode 上设置永久的递归监​​视，这些监视在触发时不会被删除，并且会以递归方式触发注册的 znode 以及任何子 znode 上的更改。

保证

ZooKeeper 非常快速且非常简单。但是，由于它的目标是成为构建更复杂服务（例如同步）的基础，因此它提供了一组保证。这些是：

• 顺序一致性 - 来自客户端的更新将按发送顺序应用。
• 原子性 - 更新要么成功要么失败。没有部分结果。
• 单一系统映像 - 无论连接到哪个服务器，客户端都将看到相同的服务视图。即，即使客户端故障转移到具有相同会话的不同服务器，客户端也永远不会看到系统的旧视图。
• 可靠性 - 应用更新后，它将从那时起一直存在，直到客户端覆盖更新。
• 及时性 - 系统的客户视图保证在特定时间范围内是最新的。

简单的API

ZooKeeper 的设计目标之一是提供一个非常简单的编程接口。因此，它仅支持以下操作：

• create : 在树中的某个位置创建一个节点

• delete : 删除一个节点

• exists：测试节点是否存在于某个位置

• get data : 从节点读取数据

• set data：将数据写入节点

• get children : 检索节点的子节点列表

• sync : 等待数据被传播

可靠性

为了显示系统在注入故障时随时间的行为，我们运行了一个由 7 台机器组成的 ZooKeeper 服务。我们运行了与之前相同的饱和基准测试，但这次我们将写入百分比保持在 30% 不变，这是我们预期工作负载的保守比例。

从这张图中有一些重要的观察结果。首先，如果跟随者失败并快速恢复，那么即使出现故障，ZooKeeper 也能够维持高吞吐量。但也许更重要的是，领导者选举算法允许系统足够快地恢复以防止吞吐量大幅下降。在我们的观察中，ZooKeeper 花费不到 200 毫秒的时间来选举一个新的领导者。第三，随着追随者的恢复，一旦他们开始处理请求，ZooKeeper 能够再次提高吞吐量。