Zookeeper 基础

在深入了解 ZooKeeper 的工作之前，让我们先了解一下 ZooKeeper 的基本概念。 我们将在本章中讨论以下主题：

• 架构
• 分层命名空间
• 会话
• 监控

ZooKeeper 的架构

看看下图。 它描述了 ZooKeeper 的“客户端-服务器架构”。

ZooKeeper 体系结构中的每个组件都在下表中进行了解释。

分层命名空间

下图描述了用于内存表示的 ZooKeeper 文件系统的树结构。 ZooKeeper 节点简称为 znode。 每个 znode 都由一个名称标识，并由一系列路径 (/) 分隔。

在图中，首先你有一个由 / 分隔的根 znode。 在 root 下，你有两个逻辑命名空间 config 和 workers。

config 命名空间用于集中配置管理，workers 命名空间用于命名。

在 config 命名空间下，每个 znode 最多可以存储 1MB 的数据。 这类似于 UNIX 文件系统，只是父 znode 也可以存储数据。 该结构的主要目的是存储同步数据和描述 znode 的元数据。 这种结构称为 ZooKeeper 数据模型。

ZooKeeper 数据模型中的每个 znode 都维护一个 stat 结构。 stat 仅提供 znode 的元数据。 它由版本号、操作控制列表 (ACL)、时间戳和数据长度组成。

• 版本号 - 每个 znode 都有一个版本号，这意味着每次与 znode 关联的数据发生变化时，其对应的版本号也会增加。 当多个 zookeeper 客户端试图在同一个 znode 上执行操作时，版本号的使用很重要。
• 操作控制列表 (ACL) - ACL 基本上是一种用于访问 znode 的身份验证机制。 它管理所有 znode 读写操作。
• 时间戳 - 时间戳表示从 znode 创建和修改开始经过的时间。 它通常以毫秒表示。 ZooKeeper 通过“事务 ID”(zxid) 识别对 znode 的每个更改。 Zxid 是唯一的，并为每个事务维护时间，以便我们可以轻松识别从一个请求到另一个请求所经过的时间。
• 数据长度 - 存储在 znode 中的数据总量是数据长度。 我们最多可以存储 1MB 的数据。

Znode 的类型

Znodes被分类为持久性、顺序性和短暂性。

• 持久 znode - 即使在创建该特定 znode 的客户端断开连接后，持久 znode 仍然存在。 默认情况下，除非另有说明，否则所有 znode 都是持久的。
• 临时 znode - 临时 znode 处于活动状态，直到客户端还活着。 当客户端与 ZooKeeper 整体断开连接时，临时 znode 会自动删除。 出于这个原因，只有临时 znode 不允许再有孩子。 如果一个临时 znode 被删除，那么下一个合适的节点将填补它的位置。 临时 znode 在领导者选举中起着重要作用。
• 顺序 znode - 顺序 znode 可以是持久的或短暂的。 当一个新的 znode 创建为顺序 znode 时，ZooKeeper 通过将 10 位序列号附加到原始名称来设置 znode 的路径。 例如，如果将路径为 /myapp 的 znode 创建为顺序 znode，ZooKeeper 会将路径更改为 /myapp0000000001 并将下一个序列号设置为 0000000002。如果同时创建两个顺序 znode，则 ZooKeeper 永远不会使用相同的

会话

会话对于 ZooKeeper 的运行非常重要。 会话中的请求按 FIFO 顺序执行。 一旦客户端连接到服务器，会话将被建立并且会话 ID 被分配给客户端。

客户端以特定的时间间隔发送心跳以保持会话有效。 如果 ZooKeeper ensemble 在超过服务启动时指定的时间段（会话超时）后没有从客户端接收到心跳，则它决定客户端死亡。

会话超时通常以毫秒表示。 当会话因任何原因结束时，在该会话期间创建的临时 znode 也会被删除。

Watches 监控

监控是客户端获取有关 ZooKeeper 整体变化的通知的一种简单机制。 客户端可以在读取特定 znode 时设置监视。 对于任何 znode（客户端在其上注册）的更改，Watches 都会向已注册的客户端发送通知。

Znode 更改是与 znode 关联的数据的修改或 znode 子节点的更改。 Watches 只触发一次。 如果客户端再次需要通知，则必须通过另一个读取操作来完成。 当连接会话过期时，客户端将断开与服务器的连接，相关的 Watch 也将被删除。