Zookeeper 基本使用

Zookeeper 基本使用

Zookeeper 系统模型

Zookeeper 数据模型 ZNode

在 Zookeeper 中，数据信息被保存在一个个数据节点上，这些节点被称为 ZNode。ZNode 是 Zookeeper 中最小的数据单位，在ZNode 下面又可以再挂 ZNode，这样一层层下去就形成了一个层次化命名空间 ZNode Tree，它采用了类似文件系统的层级树状结构进行管理。见下图示例：

在 zookeeper 中，每一个数据节点都是一个 ZNode，上图根目录下有两个节点，分别是：app1和app2，其中app1下面又有三个子节点，所有 ZNode 按层次化进行组织，形成这么一棵树，ZNode 的节点路径标识方式和Unix文件系统路径非常相似，都是由一系列斜杠（/）进行分割的路径表示，开发人员可以向这个节点写入数据，也可以在这个节点下面创建子节点。

ZNode 的类型

zookeeper 的ZNode Tree 是由一系列数据节点组成的，那接下来，我们就对数据节点做详细讲解：

zookeeper 节点类型可以分为三大类：

• 持久性节点（Persistent）

• 临时性节点（Ephemeral）

• 顺序性节点（Sequential）

在开发中创建节点的时候通过组合看生成一下几种节点类型：持久节点、持久顺序节点、临时节点、临时顺序节点，不同类型的节点则会有不同的生命周期

• 持久节点：

  是zookeeper 中最常见的一种节点类型，所谓持久节点，就是指节点被创建后会一直存在服务器，直到删除操作主动清除。

• 持久顺序节点：

  就是有顺序的持久节点，持久顺序节点特性和持久节点是一样的，只是额外特性表现在顺序上。顺序特性实质是在创建节点的时候，会在节点名后面加上一个数字后缀，来表示其顺序。

• 临时节点：

  就是会被自动清理掉的节点，它的生命周期和客户端会话绑定在一起，客户端会话结束，节点就会被删除掉。与持久节点不同的是，临时节点不能创建子节点。

• 临时顺序节点：

  就是有顺序的临时节点，和持久节点一样的是，在其创建的时候会在节点名后面加上数字后缀

事务ID

事务是对物理和抽象的应用状态上的操作集合。往往在现在的概念中，狭义上的事务通常指的是数据库事务，一般包含了一系列对数据库有序的读写操作，这些数据库事务具有所谓的ACID特性，即原子性（Atomic）、一致性（Consistency）、隔离性（Isolation）、和持久性（Durability）。

而在zookeeper中，事务是指能够改变zookeeper服务器状态的操作，我们也称之为事务操作或者更新操作，一般包括数据节点创建与删除、数据节点内容更新等操作。对于每一个事务请求，zookeeper 都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID 对应一次更新操作，从这些 ZXID 中可以间接地识别出 zookeeper 处理这些更新操作请求的全局顺序。

ZNode 的状态信息

整个 ZNode 节点内容包括两部分：节点数据内容和节点状态信息。图中 “这是修改后的内容” 是数据内容，其他的属于状态信息，那么这些状态信息都有什么含义呢？

cZxid 就是 Create ZXID，表示节点被创建时的事务ID。

ctime 就是 Create Time，表示节点创建时间。

mZxid 就是 Modified ZXID，表示节点最后⼀次被修改时的事务ID。

mtime 就是 Modified Time，表示节点最后⼀次被修改的时间。

pZxid 表示该节点的子节点列表最后⼀次被修改时的事务 ID。只有⼦节点列表变更才会更新 pZxid， ⼦节点内容变更不会更新。

cversion 表示⼦节点的版本号。

dataVersion 表示内容版本号。

aclVersion 标识acl版本

ephemeralOwner 表示创建该临时节点时的会话 sessionID，如果是持久性节点那么值为 0

dataLength 表示数据⻓度。

numChildren 表示直系子节点数。

Watcher —— 数据变更通知

zookeeper 使用 Watcher 机制实现分布式数据的发布/订阅功能。

一个典型的发布/订阅模型系统定义了一种 一对多 的订阅关系，能够让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，始它们能够做出相应的处理。

在 zookeeper 中，引入 Watcher 机制来实现这种分布式的通知功能。zookeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

整个 Watcher 注册与通知过程如图所示：

zookeeper 的 Watcher 机制主要包括 客户端线程、客户端WatcherManager、Zookeeper服务器 三部分。

具体工作流程为：

• 客户端在向 zookeeper 服务器注册的同时，会将 Watcher 对象存储在客户端的 WatcherManager 中。
• 当 Zookeeper 服务器触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatcherManager 中取出对应的 Watcher 对象来执行回调逻辑

ACL —— 保障数据的安全

zookeeper 作为一个分布式协调框架，其内部存储了分布式系统运行时状态的元数据，这些元数据会直接影响基于 zookeeper 进行构造的分布式系统的运行状态。因此，如何保障系统中数据的安全，从而避免因误操作带来的数据随意变更而导致的数据库异常十分重要，在zookeeper中，提供了一套完善的 ACL (Access Control List) 权限控制机制来保障数据的安全。

我们可以从三个方面来理解 ACL 机制：权限模式（Scheme）、授权对象（ID）、权限（Permission），通常使用 scheme:id:permission 来标识一个有效的 ACL 信息。

权限模式：Scheme

权限模式用来确定权限验证过程中使用的检验策略，有如下四种模式：

• IP：

  IP 模式就是通过IP地址粒度来进行权限控制，如ip:192.168.0.110 标识权限控制针对该IP地址，同时IP模式可以按照网段方式进行配置，如 ip:192.168.0.1/24 表示针对 192.168.0.* 这个网段进行权限控制

• Digest：

  Digest 是最常用的权限控制模式，更符合我们对全乡控制的认识，其使用 username:password 形式配置了权限标识后，zookeeper 会先后对其进行 SHA-1 加密和 BASE64编码

• World：

  World 是一种最开放的权限控制模式，这种权限控制方式几乎没有任何作用，数据节点的访问权限对所有用户开放，即所有用户都可以在不进行任何权限校验的情况下操作 zookeeper 上的数据。另外，world 模式也可以看做是一种特殊的 Digest 模式，它只有一个权限标识，即 world:anyone

• Supper：

  supper模式，顾名思义就是超级用户的意思，也是一种特殊的 Digest 模式。在Super 模式下，超级用户可以对任意 zookeeper 上的数据节点进行任何操作

授权对象 ID：

授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器等。在不同的权限模式下，授权对象是不同的，表中列出了各个权限模式和权限对象之间的对应关系

权限模式	授权对象
IP	通常是一个IP地址或者是IP段
Digest	自定义，通常是 username:BASE64(SHA-1(username:password))
World	只有一个ID: anyone
Super	超级用户

权限：

权限就是指哪些通过权限检查后可以被允许执行的操作。在zookeeper中，所有对数据的操作权限分为以下五大类：

• CREATE（C）

  数据节点的创建权限，允许授权对象在该数据节点下创建子节点。

• DELETE（D）

  子节点的删除权限，允许授权对象删除该数据节点的子节点。

• READ（R）

  数据节点的读取权限，允许授权对象访问改数据节点并读取其数据内容或子节点列表等。

• WRITE（W）

  数据节点的更新权限，允许授权对象对该数据节点进行更新操作。

• ADMIN（A）

  数据节点的管理权限，允许授权对象对该数据数据节点进行ACL相关的设置操作