Zookeeper：存储模型

关于

ZooKeeper提供的名称空间与标准文件系统的名称空间非常相似：

• 名称是由斜杠（/）分隔的路径元素序列。
• ZooKeeper命名空间中的每个节点都由一个路径标识。

与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以有与其关联的数据以及子节点：这就像有一个文件系统，允许一个文件也成为一个目录。

• （ZooKeeper被设计用来存储协调数据：状态信息、配置、位置信息等，因此存储在每个节点上的数据通常很小，在字节到千字节的范围内。）

我们使用znode这个术语来清楚地说明我们所说的ZooKeeper数据节点。

• znode维护一个stat结构，其中包含数据更改、ACL更改和时间戳的版本号，以允许缓存验证和协调更新。每次znode的数据更改时，版本号都会增加。例如，每当客户机检索数据时，它也会接收数据的版本。
• 存储在命名空间中每个znode上的数据是原子读写的。Reads获取与znode相关的所有数据字节，write替换所有数据。每个节点都有一个访问控制列表（ACL），限制谁可以做什么。
• ZooKeeper也有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就存在。当会话结束时，znode被删除。

Znode

每个znode由一个名称标识，并用路径(/)序列分隔。

Znode 兼具文件和目录两种特点：既像文件一样维护着数据长度、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。

每个Znode由三个部分组成：

1. stat：此为状态信息，描述该Znode版本、权限等信息：
   • 版本号：每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。
     • 当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。
   • 操作控制列表（ACL）：ACL基本上是访问znode的认证机制。
     • 它管理所有znode读取和写入操作。
   • 时间戳：时间戳表示创建和修改znode所经过的时间。通常以毫秒为单位。
     • ZooKeeper用“事务ID”（zxid）标识znode的每个更改：Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。
   • 数据长度：存储在znode中的数据总量是数据长度。
     • 最多可以存储 1 MB 的数据。
2. data：与该Znode关联的数据。
3. children：该Znode下的节点。

Znode的类型

Znode被分为以下类型：

1. 持久节点（persistent）：即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。
   • 默认情况下，除非另有说明，否则所有znode都是持久的。
2. 临时节点（ephemeral）：客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。
   • 因此，只有临时节点不允许有子节点。
   • 如果临时节点被删除，则下一个合适的节点将填充其位置。
   • 临时节点在leader选举中起着重要作用。【？？？】
3. 顺序节点（sequential）：当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将 10 位的序列号附加到原始名称来设置znode的路径。

   例如，如果将具有路径 /myapp 的znode创建为顺序节点，则ZooKeeper会将路径更改为 /myapp0000000001 ，并将下一个序列号设置为 0000000002。

   • 如果两个顺序节点是同时创建的，那么ZooKeeper不会对每个znode使用相同的数字。
   • 顺序节点可以是持久的或临时的。
   • 顺序节点在锁定和同步中起重要作用。【？？？】

Znode 的状态属性

命令行终端执行 get 命令显示节点的属性，如下：

$ get /runoob

其中第一行显示的 0 是该节点的 value 值。

其中，各项属性含义如下：

属性	含义
cZxid	创建节点时的事务ID
ctime	创建节点时的时间
mZxid	最后修改节点时的事务ID
mtime	最后修改节点时的时间
pZxid	表示该节点的子节点列表最后一次修改的事务ID。 添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID （只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid）
cversion	子节点版本号，子节点每次修改版本号加1
dataversion	数据版本号，数据每次修改该版本号加1
aclversion	权限版本号，权限每次修改该版本号加1
ephemeralOwner	创建该临时节点的会话的sessionID。 如果该节点是持久节点，那么这个属性值为 0
dataLength	该节点的数据长度
numChildren	该节点拥有子节点的数量（只统计直接子节点的数量）

节点特性

1. 同一级节点 key 名称是唯一的。

   

2. 创建节点时，必须要带上全路径。

   

3. session 关闭，临时节点清除。

4. 自动创建顺序节点。

   

5. watch 机制，监听节点变化。

   事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。

   • 特别注意：监听事件被单次触发后，事件就失效了。
6. delete 命令只能一层一层删除。

   

   • 新版本可以通过 deleteall 命令递归删除。
   • rmr 命令用于递归删除。

这些节点特性的存在使 zookeeper 开发出不同的场景应用，如：

• 数据发布/订阅
• 负载均衡
• 分布式协调/通知
• 集群管理
• 集群管理
• master 管理
• 分布式锁（临时节点）
• 分布式队列

权限控制 ACL

zookeeper 的 ACL（Access Control List，访问控制表）权限在生产环境是特别重要的。

• ACL 权限可以针对节点设置相关读写等权限，保障数据安全性。
• permissions 可以指定不同的权限范围及角色。【？？？】

ACL 命令行

• getAcl 命令：获取某个节点的 acl 权限信息。
• setAcl 命令：设置某个节点的 acl 权限信息。
• addauth 命令：输入认证授权信息，注册时输入明文密码，加密形式保存。

ACL 构成

zookeeper 的 acl 通过 [scheme:id:permissions] 来构成权限列表。

1. scheme：代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。【？？？】
2. id：代表允许访问的用户。
3. permissions：权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限：

   创建权限 create(c)、删除权限 delete(d)、读权限 read(r)、写权限 write(w)、管理权限admin(a)。

scheme

1. world：代表开放式权限。

   如下，查看默认节点权限，再更新节点 permissions 权限部分为 crwa，结果删除节点失败（没有删除权限 d）：

   

2. auth：用于授予权限，注意需要先创建用户。

   

3. digest：退出当前用户，重新连接终端，digest 可用于账号密码登录和验证。

   

4. IP：限制 IP 地址的访问权限。

   如下，把权限设置给 IP 地址为 192.168.3.7 后，当前 IP 为 192.168.3.38 已经没有访问权限。