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 能够再次提高吞吐量。