“Zookeeper：存储模型”的版本间差异

2021年9月28日 (二) 20:25的最新版本

关于

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

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

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

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

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

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

Znode

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

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

每个Znode由三个部分组成：

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

Znode的类型

Znode被分为以下类型：

持久节点（persistent）：即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。
- 默认情况下，除非另有说明，否则所有znode都是持久的。
临时节点（ephemeral）：客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。
- 因此，只有临时节点不允许有子节点。
- 如果临时节点被删除，则下一个合适的节点将填充其位置。
- 临时节点在leader选举中起着重要作用。【？？？】
顺序节点（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	该节点拥有子节点的数量（只统计直接子节点的数量）

节点特性

同一级节点 key 名称是唯一的。
创建节点时，必须要带上全路径。
session 关闭，临时节点清除。
自动创建顺序节点。
watch 机制，监听节点变化。
事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。
- 特别注意：监听事件被单次触发后，事件就失效了。
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] 来构成权限列表。

scheme：代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。【？？？】
id：代表允许访问的用户。
permissions：权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限：
创建权限 create(c)、删除权限 delete(d)、读权限 read(r)、写权限 write(w)、管理权限admin(a)。

scheme

world：代表开放式权限。
如下，查看默认节点权限，再更新节点 permissions 权限部分为 crwa，结果删除节点失败（没有删除权限 d）：
auth：用于授予权限，注意需要先创建用户。
digest：退出当前用户，重新连接终端，digest 可用于账号密码登录和验证。
IP：限制 IP 地址的访问权限。
如下，把权限设置给 IP 地址为 192.168.3.7 后，当前 IP 为 192.168.3.38 已经没有访问权限。

@@ 第2行： / 第2行： @@
 == 关于 ==
+ZooKeeper提供的名称空间与标准文件系统的名称空间非常相似：
+* 名称是由斜杠（'''/'''）分隔的路径元素序列。
+* ZooKeeper命名空间中的每个节点都由一个路径标识。
+: [[File:Zookeeper：层次命名空间.png|400px]]
+与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以有与其关联的'''数据'''以及'''子节点'''：这就像有一个文件系统，允许一个文件也成为一个目录。
+*（ZooKeeper被设计用来存储协调数据：状态信息、配置、位置信息等，因此存储在每个节点上的数据通常很小，在字节到千字节的范围内。）
+我们使用'''znode'''这个术语来清楚地说明我们所说的ZooKeeper数据节点。
+* znode维护一个stat结构，其中包含数据更改、ACL更改和时间戳的版本号，以允许缓存验证和协调更新。每次znode的数据更改时，版本号都会增加。例如，每当客户机检索数据时，它也会接收数据的版本。
+* 存储在命名空间中每个znode上的数据是原子读写的。Reads获取与znode相关的所有数据字节，write替换所有数据。每个节点都有一个访问控制列表（ACL），限制谁可以做什么。
+* ZooKeeper也有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就存在。当会话结束时，znode被删除。
+== Znode ==
+每个znode由一个'''名称'''标识，并用路径('''/''')序列分隔。
+Znode 兼具'''文件'''和'''目录'''两种特点：既像文件一样维护着数据长度、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。
+每个Znode由三个部分组成：
+# '''stat'''：此为状态信息，描述该Znode版本、权限等信息：
+#* '''版本号'''：每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。
+#** 当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。
+#* '''操作控制列表'''（ACL）：ACL基本上是访问znode的认证机制。
+#** 它管理所有znode读取和写入操作。
+#* '''时间戳'''：时间戳表示创建和修改znode所经过的时间。通常以毫秒为单位。
+#** ZooKeeper用“事务ID”（'''zxid'''）标识znode的每个更改：Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。
+#* '''数据长度'''：存储在znode中的数据总量是数据长度。
+#** 最多可以存储 '''1 MB''' 的数据。
+# '''data'''：与该Znode关联的数据。
+# '''children'''：该Znode下的节点。
+=== Znode的类型 ===
+Znode被分为以下类型：
+# '''持久节点'''（persistent）：即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。
+#* 默认情况下，除非另有说明，否则所有znode都是持久的。
+# '''临时节点'''（ephemeral）：客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。
+#* 因此，只有临时节点不允许有子节点。
+#* 如果临时节点被删除，则下一个合适的节点将填充其位置。
+#* 临时节点在'''leader选举'''中起着重要作用。【？？？】
+# '''顺序节点'''（sequential）：当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将 '''10''' 位的序列号附加到原始名称来设置znode的路径。
+#: 例如，如果将具有路径 /myapp 的znode创建为顺序节点，则ZooKeeper会将路径更改为 /myapp0000000001 ，并将下一个序列号设置为 0000000002。
+#* 如果两个顺序节点是同时创建的，那么ZooKeeper不会对每个znode使用相同的数字。
+#* 顺序节点可以是持久的或临时的。
+#* 顺序节点在'''锁定'''和'''同步'''中起重要作用。【？？？】
+=== Znode 的状态属性 ===
+命令行终端执行 '''get''' 命令显示节点的属性，如下：
+<syntaxhighlight lang="bash" highlight="">
+$ get /runoob
+</syntaxhighlight>
+: [[File:Zookeeper：显示节点属性.png|400px]]
+: 其中第一行显示的 0 是该节点的 value 值。
+其中，各项属性含义如下：
+{| class="wikitable"
+! 属性 !! 含义
+|-
+| cZxid || 创建节点时的事务ID
+|-
+| ctime || 创建节点时的时间
+|-
+| mZxid || 最后修改节点时的事务ID
+|-
+| mtime || 最后修改节点时的时间
+|-
+| pZxid || 表示该节点的子节点列表最后一次修改的事务ID。
+* 添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID
+*:（只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid）
+|-
+| cversion || 子节点版本号，子节点每次修改版本号加1
+|-
+| dataversion || 数据版本号，数据每次修改该版本号加1
+|-
+| aclversion || 权限版本号，权限每次修改该版本号加1
+|-
+| ephemeralOwner || 创建该临时节点的会话的sessionID。
+* 如果该节点是持久节点，那么这个属性值为 0
+|-
+| dataLength || 该节点的数据长度
+|-
+| numChildren || 该节点拥有子节点的数量（只统计直接子节点的数量）
+|}
+=== 节点特性 ===
+# 同一级节点 key 名称是唯一的。
+#: [[File:Zookeeper：节点特性1：同级节点key必须唯一.png|400px]]
+# 创建节点时，必须要带上全路径。
+#: [[File:Zookeeper：节点特性2：创建节点时必须带上全路径.png|400px]]
+# session 关闭，临时节点清除。
+#:
+# 自动创建顺序节点。
+#: [[File:Zookeeper：节点特性4：自动创建顺序节点.png|400px]]
+# watch 机制，监听节点变化。
+#: 事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。
+#* 特别注意：监听事件被单次触发后，事件就失效了。
+# delete 命令只能一层一层删除。
+#: [[File:Zookeeper：节点特性6：delete 命令只能一层一层删除.png|400px]]
+#* 新版本可以通过 '''deleteall''' 命令递归删除。
+#* '''rmr''' 命令用于递归删除。
+这些节点特性的存在使 zookeeper 开发出不同的场景应用，如：
+* 数据发布/订阅
+* 负载均衡
+* 分布式协调/通知
+* 集群管理
+* 集群管理
+* master 管理
+* 分布式锁（临时节点）
+* 分布式队列
+== 权限控制 ACL ==
+zookeeper 的 ACL（Access Control List，访问控制表）权限在生产环境是特别重要的。
+* ACL 权限可以针对节点设置相关读写等权限，保障数据安全性。
+* permissions 可以指定不同的权限范围及角色。【？？？】
+=== ACL 命令行 ===
+* '''getAcl''' 命令：获取某个节点的 acl 权限信息。
+* '''setAcl''' 命令：设置某个节点的 acl 权限信息。
+* '''addauth''' 命令：输入认证授权信息，注册时输入明文密码，加密形式保存。
+=== ACL 构成 ===
+zookeeper 的 acl 通过 '''[scheme:id:permissions]''' 来构成权限列表。
+# '''scheme'''：代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。【？？？】
+# '''id'''：代表允许访问的用户。
+# '''permissions'''：权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限：
+#: 创建权限 create(c)、删除权限 delete(d)、读权限 read(r)、写权限 write(w)、管理权限admin(a)。
+==== scheme ====
+# '''world'''：代表'''开放式权限'''。
+#: 如下，查看默认节点权限，再更新节点 permissions 权限部分为 crwa，结果删除节点失败（没有删除权限 d）：
+#: [[File:Zookeeper：ACL：world 实例.png|600px]]
+# '''auth'''：用于'''授予权限'''，注意需要先创建用户。
+#: [[File:Zookeeper：ACL：auth 实例.png|600px]]
+# '''digest'''：退出当前用户，重新连接终端，digest 可用于账号密码登录和验证。
+#: [[File:Zookeeper：ACL：digest 实例.png|600px]]
+# '''IP'''：'''限制 IP 地址'''的访问权限。
+#: 如下，把权限设置给 IP 地址为 192.168.3.7 后，当前 IP 为 192.168.3.38 已经没有访问权限。
+#: [[File:Zookeeper：ACL：IP 实例.png|600px]]