ZooKeeper 的数据模型

本期将给大家介绍下 ZooKeeper 内部是如何做到分布式数据一致性的。

ZooKeeper 使用了一个树形结构的命名空间来表示其数据结构，其视图结构和标准的 Unix 文件系统非常类似，但没有引入传统文件系统中目录和文件等相关概念，而是将 ZooKeeper 树中的每一个节点都称之为一个 Znode。其数据结构如下图所示。

类似文件系统的目录树，ZooKeeper 树中的每个节点都可以拥有子节点，而不同的是，每个 Znode 节点都存储了数据信息，同时也提供了对节点信息的监控等操作。

1. Znode 的数据模型

Znode 是 ZooKeeper 中数据的最小单元，每个 Znode 都兼具文件和目录两种特点，既能像文件一样保存和维护数据，又可以由一系列使用斜杠(/)进行分割的方式作为路径标识的一部分。每个 Znode 都有以下三部分组成。

• Stat：状态信息，用于存储该 Znode 的版本、权限、时间戳等信息；
• Data：实际存储的数据；
• Children：对子节点的信息描述；

需要特别说明的是，Znode 节点虽然可以存储数据信息，但它并不能像数据库那样存储大量的数据，Znode 的设计初衷就是存储分布式应用中的配置文件、集群状态等元数据信息。

2. Znode 的控制访问

1）ACL

ACL(Access Control List) 为访问控制列表，应用程序会根据实际需求将用户分为只读、只写以及读写用户，每一个 Znode 节点都会有一个 ACL 用来约束不同的用户对节点的访问权限。

2）原子操作

每一个 Znode 节点上都具有原子操作的特性，读操作将获取与节点相关的数据，写操作将替换节点上的数据，上期文章中讲到 ZooKeeper 都会为每一个事务请求分配一个全局唯一的事务编号 Zxid，每一个 Zxid 就对应一次更新操作，并可以通过 Zxid 来识别出更新操作请求的全局顺序。

3. Znode 的节点类型

ZooKeeper 中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。

1）临时节点

临时节点常被应用于心跳监控，举个栗子，设置过期时间为 30s，要求各个子节点对应的服务端每 5s 发送一次心跳到 ZooKeeper 集群，当服务端连续 30s 没有向 ZooKeeper 汇报心跳信息，也就是连续6次没有收到心跳信息，就认为该节点宕机了，并将其从服务列表中移除。

临时节点的生命周期依赖于创建它们的会话(Session)。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。

另外，ZooKeeper 的临时节点不允许拥有子节点。

2）永久节点

永久节点的数据会一直存储着，直到用户调用接口将其数据删除，该节点一般用于存储一些永久性的配置信息。

4. Znode 的监听器机制（ 面试重点）

ZooKeeper 的每个节点上都有一个 Watcher 用于监控节点数据的变化，当节点状态发生改变时（Znode 新增、删除、修改）将会触发 Wahcher 所对应的操作。在 Watcher 被触发时，ZooKeeper 会向监控该节点的客户端发送一条通知说明节点的变化情况。

具体实现流程就是，客户端向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当 ZooKeeper 服务器端触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 中取出对应的 Watcher 对象来执行回调逻辑。

---

以上是本期分享，如有帮助请 点关注 支持下哦～
下期继续讲解 ZooKeeper 内容。

可扫码关注