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

2021年5月14日 (五) 02:35的版本

关于

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

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

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

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

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

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

下图描述了用于内存表示的ZooKeeper文件系统的树结构：【？？？】

文件:Zookeeper：层次命名空间：“config”与“workers”逻辑命名空间.png

在图中，首先有一个由“/”分隔的znode。在根目录下，有两个逻辑命名空间：

config 命名空间：用于集中式配置管理；
- 在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper 数据模型。
workers 命名空间：用于命名。

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 机制，监听节点变化 delete 命令只能一层一层删除

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

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

权限控制 ACL

@@ 第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被删除。
+下图描述了用于内存表示的ZooKeeper文件系统的树结构：【？？？】
+: [[File:Zookeeper：层次命名空间：“config”与“workers”逻辑命名空间.png|600px]]
+在图中，首先有一个由“'''/'''”分隔的znode。在根目录下，有两个逻辑命名空间：
+# '''config''' 命名空间：用于'''集中式配置管理'''；
+#* 在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper 数据模型。
+# '''workers''' 命名空间：用于'''命名'''。
+== 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|600px]]
+其中第一行显示的 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 名称是唯一的。
+创建节点时，必须要带上全路径
+session 关闭，临时节点清除
+自动创建顺序节点
+watch 机制，监听节点变化
+delete 命令只能一层一层删除
+这些节点特性的存在使 zookeeper 开发出不同的场景应用，如：
+* 数据发布/订阅
+* 负载均衡
+* 分布式协调/通知
+* 集群管理
+* 集群管理
+* master 管理
+* 分布式锁（临时节点）
+* 分布式队列
+== 权限控制 ACL ==