Zookeeper：存储模型 - 版本历史

Eijux：/* 关于 */

2021-09-28T12:25:05Z

关于

←上一版本		2021年9月28日 (二) 20:25的版本
第14行：		第14行：
	* 存储在命名空间中每个znode上的数据是原子读写的。Reads获取与znode相关的所有数据字节，write替换所有数据。每个节点都有一个访问控制列表（ACL），限制谁可以做什么。		* 存储在命名空间中每个znode上的数据是原子读写的。Reads获取与znode相关的所有数据字节，write替换所有数据。每个节点都有一个访问控制列表（ACL），限制谁可以做什么。
	* ZooKeeper也有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就存在。当会话结束时，znode被删除。		* ZooKeeper也有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就存在。当会话结束时，znode被删除。



	~~下图描述了用于内存表示的ZooKeeper文件系统的树结构：【？？？】~~
	~~: [[File:Zookeeper：层次命名空间：“config”与“workers”逻辑命名空间.png\|600px]]~~
	~~在图中，首先有一个由“'''/'''”分隔的znode。在根目录下，有两个逻辑命名空间：~~
	~~# '''config''' 命名空间：用于'''集中式配置管理'''；~~
	#* 在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper 数据模型。
	~~# '''workers''' 命名空间：用于'''命名'''。~~

	== Znode ==		== Znode ==

Eijux：Eijux移动页面Zookeeper：层次命名空间（Hierarchical namespace）至Zookeeper：存储模型，不留重定向

2021-09-28T10:13:29Z

Eijux移动页面Zookeeper：层次命名空间（Hierarchical namespace）至Zookeeper：存储模型，不留重定向

←上一版本	2021年9月28日 (二) 18:13的版本
（没有差异）

Eijux：/* 权限控制 ACL */

2021-05-14T10:57:47Z

权限控制 ACL

←上一版本		2021年5月14日 (五) 18:57的版本
第126行：		第126行：

	== 权限控制 ACL ==		== 权限控制 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]]

Eijux：/* 节点特性 */

2021-05-14T10:38:12Z

节点特性

←上一版本		2021年5月14日 (五) 18:38的版本
第98行：		第98行：

	=== 节点特性 ===		=== 节点特性 ===
	同一级节点 key 名称是唯一的。		# 同一级节点 key 名称是唯一的。
	~~创建节点时，必须要带上全路径~~		#: [[File:Zookeeper：节点特性1：同级节点key必须唯一.png\|400px]]
	session ~~关闭，临时节点清除~~		# 创建节点时，必须要带上全路径。
	~~自动创建顺序节点~~		#: [[File:Zookeeper：节点特性2：创建节点时必须带上全路径.png\|400px]]
	watch ~~机制，监听节点变化~~		# session 关闭，临时节点清除。
	delete 命令只能一层一层删除		#:
			# 自动创建顺序节点。
			#: [[File:Zookeeper：节点特性4：自动创建顺序节点.png\|400px]]
			# watch 机制，监听节点变化。
			#: 事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。
			#* 特别注意：监听事件被单次触发后，事件就失效了。
			# delete 命令只能一层一层删除。
			#: [[File:Zookeeper：节点特性6：delete 命令只能一层一层删除.png\|400px]]
			#* 新版本可以通过 '''deleteall''' 命令递归删除。
			#* '''rmr''' 命令用于递归删除。

Eijux：/* Znode 的状态属性 */

2021-05-13T18:36:07Z

Znode 的状态属性

←上一版本		2021年5月14日 (五) 02:36的版本
第63行：		第63行：
	$ get /runoob		$ get /runoob
	</syntaxhighlight>		</syntaxhighlight>
	: [[File:Zookeeper：显示节点属性.png\|~~600px~~]]		: [[File:Zookeeper：显示节点属性.png\|400px]]
	其中第一行显示的 0 是该节点的 value 值。		: 其中第一行显示的 0 是该节点的 value 值。

2021年5月13日 (四) 18:35 Eijux

2021-05-13T18:35:35Z

←上一版本		2021年5月14日 (五) 02:35的版本
第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 ==

Eijux：建立内容为“category:Zookeeper == 关于 ==”的新页面

2021-05-13T17:39:41Z

建立内容为“category:Zookeeper == 关于 ==”的新页面

新页面

[[category:Zookeeper]]

== 关于 ==

Zookeeper：存储模型 - 版本历史

Eijux：​/* 关于 */

Eijux：​Eijux移动页面Zookeeper：层次命名空间（Hierarchical namespace）至Zookeeper：存储模型，不留重定向

Eijux：​/* 权限控制 ACL */

Eijux：​/* 节点特性 */

Eijux：​/* Znode 的状态属性 */