0
0

ZooKeeper特性与节点数据类型详解

CAP和BASE理论

参考下面文章的CAP、BASE、一致性分类部分。
传送门：https://blog.csdn.net/u010355502/article/details/132307054

什么是ZooKeeper

官网：https://zookeeper.apache.org

ZooKeeper是一个开源的分布式协调框架，是Apache Hadoop的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

注册中心图示：
image.png

ZooKeeper安装

参考下面安装文章。
传送门：https://blog.csdn.net/u010355502/article/details/132308824

常见的Cli命令

官网命令介绍：https://zookeeper.apache.org/doc/r3.8.0/zookeeperCLI.html

  • help

显示所有操作命令

  • ls
ls[-s][-w][-R] path

使用 ls 命令来查看/监听当前 znode 的子节点。

-s: 节点状态信息（时间戳、版本号、数据大小等）
-w: 监听子节点变化
-R: 表示递归的获取

  • create
create [-s][-e][-c][-t ttl] path [data][acl]

创建节点。

-s: 创建有序节点
-e: 创建临时节点
-c: 创建一个容器节点
t ttl: 创建一个TTL节点，

-t 时间

（单位毫秒）
data: 节点的数据，可选，如果不使用时，节点数据就为null
acl: 访问控制

  • get
get [-s][-w] path

获取节点数据信息。

-s: 节点状态信息（时间戳、版本号、数据大小等）
-w: 监听节点变化

  • set
set[-s][-v version] path data

设置节点数据。

-s: 表示节点为顺序节点
-v: 指定版本号

  • getAcl
getAcl [-s] path

获取节点的访问控制信息。

-s: 节点状态信息（时间戳、版本号、数据大小等）

  • setAcl
setAcl [-s][-v version][-R] path acl

设置节点的访问控制列表。

-s: 节点状态信息（时间戳、版本号、数据大小等）
-v: 指定版本号
-R: 递归的设置

  • stat
stat[-w] path

查看节点状态信息。

  • delete
delete [-v version] path

删除某一节点，只能删除无子节点的节点。

-v: 表示节点版本号

  • deleteAll
deleteall path

递归地删除某一节点及其子节点。

  • setquota
setquota -n|-b val path

对节点增加限制。

n: 表示子节点的最大个数
b: 数据值的最大长度，-1表示无限制

ZooKeeper数据结构

ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。
图示：
image.png

ZooKeeper的数据模型是层次模型，层次模型常见于文件系统。层次模型和key-value模型是两种主流的数据模型。

ZooKeeper使用文件系统模型主要基于以下两点考虑:

  1. 文件系统的树形结构便于表达数据之间的层次关系
  2. 文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )

ZooKeeper的层次模型称作Data Tree，Data Tree的每个节点叫作ZNode。不同于文件系统，每个节点都可以保存数据，每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识，每个节点都有一个版本（version），版本从0开始计数。

源码：

publicclassDataTree{privatefinalConcurrentHashMap<String,DataNode> nodes =newConcurrentHashMap<String,DataNode>();privatefinalWatchManager dataWatches =newWatchManager();privatefinalWatchManager childWatches =newWatchManager();}publicclassDataNodeimplementsRecord{byte data[];Long acl;publicStatPersisted stat;privateSet<String> children =null;}

ZNode节点分类

一个ZNode可以是持久性的，也可以是临时性的：

  1. 持久节点（PERSISTENT）

这样的ZNode在创建之后即使发生ZooKeeper集群宕机或者client宕机也不会丢失。

  1. 临时节点（EPHEMERAL）

client宕机或者client在指定的timeout时间内没有给ZooKeeper集群发消息，这样的ZNode就会消失。

如果上面两种ZNode具备顺序性，又有以下两种znode：

  1. 持久顺序节点（PERSISTENT_SEQUENTIAL）

ZNode除了具备持久性ZNode的特点之外，ZNode的名字具备顺序性。

  1. 临时顺序节点（EPHEMERAL_SEQUENTIAL）

ZNode除了具备临时性ZNode的特点之外，ZNode的名字具备顺序性。

ZooKeeper主要用到的是以上4种节点。

  1. Container节点（3.5.3版本新增）

Container容器节点，当容器中没有任何子节点，该容器节点会被ZK定期删除（定时任务默认60s检查一次)。 和持久节点的区别是ZK服务端启动后，会有一个单独的线程去扫描所有的容器节点，当发现容器节点的子节点数量为0时，会自动删除该节点。可以用于Leader或者锁的场景中。

  1. TTL节点

带过期时间节点，默认禁用，需要在zoo.cfg中添加

extendedTypesEnabled=true

开启。注意：ttl不能用于临时节点。

示例：

# 创建持久节点
create /servers xxx
# 创建临时节点
create -e /servers/host xxx
# 创建临时有序节点
create -e -s /servers/host xxx
# 创建容器节点
create -c /container xxx
# 创建ttl节点
create -t 10/ttl

ZNode节点状态信息

[zk: localhost:2181(CONNECTED)2] stat /jay
cZxid =0x4
ctime =TueAug1512:54:52CST2023
mZxid =0x5
mtime =TueAug1512:57:21CST2023
pZxid =0x4
cversion =0
dataVersion =1
aclVersion =0
ephemeralOwner =0x0
dataLength =6
numChildren =0

参数说明：

cZxid：ZNode创建的事务id。
ctime：节点创建时的时间戳。
mZxid：ZNode被修改的事务id，即每次对ZNode的修改都会更新mZxid。
对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id），通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。
pZxid：表示该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID（注意：只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid）。
mtime：节点最新一次更新发生时的时间戳。
cversion：子节点的版本号。当ZNode的子节点有变化时，cversion的值就会增加1。
dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
ephemeralOwner：如果该节点为临时节点，ephemeralOwner值表示与该节点绑定的session id。如果不是, ephemeralOwner值为0（持久节点）。
在client和server通信之前，首先需要建立连接，该连接称为session。连接建立后，如果发生连接超时、授权失败，或者显式关闭连接，连接便处于closed状态，此时session结束。
dataLength：数据的长度。
numChildren：子节点的数量（只统计直接子节点的数量）。

ZNode节点特性总结

  • 同一节点key名是唯一的
[zk: localhost:2181(CONNECTED)9]ls /jay
[][zk: localhost:2181(CONNECTED)10] create /jay
Node already exists: /jay
  • 创建节点时必须带上全路径
[zk: localhost:2181(CONNECTED)7] create jolin
Path must start with / character
  • session关闭，临时节点清除
  • 自动创建顺序节点
[zk: localhost:2181(CONNECTED)3] create -e-s /temp
Created /temp0000000016
[zk: localhost:2181(CONNECTED)4] create -e-s /temp
Created /temp0000000017
[zk: localhost:2181(CONNECTED)5] create -e-s /temp
Created /temp0000000018
[zk: localhost:2181(CONNECTED)6]
  • watch机制监听节点变化

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

  • delete命令只能一层一层删除

新版本可以通过deleteall命令递归删除。

  • 适用于存储和协同相关的关键数据，不适合用于大数据量存储，最大存储1M大小

监听通知（watcher）机制

一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。Watch机制建立的是长连接。
ZooKeeper采用了Watcher机制实现数据的发布订阅功能，多个订阅者可同时监听某一特定主题对象，当该主题对象的自身状态发生变化时例如节点内容改变、节点下的子节点列表改变等，会实时、主动通知所有订阅者。
Watcher机制事件上与观察者模式类似，也可看作是一种观察者模式在分布式场景下的实现方式。

Watcher的过程：

  1. 客户端向服务端注册watcher
  2. 服务端事件发生触发watcher
  3. 客户端回调watcher得到触发事件情况

注意：ZooKeeper中的Watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

支持的事件类型：

  1. None：连接建立事件
  2. NodeCreated：节点创建
  3. NodeDeleted：节点删除
  4. NodeDataChanged：节点数据变化
  5. NodeChildrenChanged：子节点列表变化
  6. DataWatchRemoved：节点监听被移除
  7. ChildWatchRemoved：子节点监听被移除

Watch机制的特性：

  1. 一次性触发

watcher是一次性的，一旦被触发就会移除，再次使用时需要重新注册客户端。

  1. 顺序回调

watcher回调是顺序串行执行的，只有回调后客户端才能看到最新的数据状态。一个watcher回调逻辑不应该太多，以免影响别的watcher执行。

  1. 轻量级

WatchEvent是最小的通信单位，结构上只包含通知状态、事件类型和节点路径，并不会告诉数据节点变化前后的具体内容。

  1. 时效性

watcher只有在当前session彻底失效时才会无效，若在session有效期内快速重连成功，则watcher依然存在，仍可接收到通知。

示例：

# 监听节点数据的变化
get -w path 
stat-w path
# 监听子节点增减的变化 ls-w path

永久性Watch

在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的功能。
之前版本的Watch是监听一次后需要再次发起监听才能持续监听。

addWatch [-m mode] path

addWatch的作用是针对指定节点添加事件监听，支持两种模式：

  1. PERSISTENT：持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
  2. PERSISTENT_RECURSIVE：持久化递归订阅，在PERSISTENT的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）。

示例：

# 新增持久监听[zk: localhost:2181(CONNECTED)11] addWatch -m PERSISTENT /keeping
# 新增节点，这里可以看出，新增持久监听时无需提前新建节点[zk: localhost:2181(CONNECTED)13] create /keeping

WATCHER::Created /keeping

WatchedEvent state:SyncConnected type:NodeCreated path:/keeping
# 新增子节点[zk: localhost:2181(CONNECTED)14] create /keeping/a
Created /keeping/a
# 仍然可以继续触发监听[zk: localhost:2181(CONNECTED)15] 
WATCHER::

WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/keeping

ACL权限控制

使用场景

参考如下文章。
传送门：https://blog.csdn.net/u010355502/article/details/132316237

ZooKeeper集群

参考如下文章。
传送门：https://blog.csdn.net/u010355502/article/details/132316065

标签： zookeeper 分布式
本文转载自: https://blog.csdn.net/u010355502/article/details/132309321
版权归原作者 Firechou 所有， 如有侵权，请联系我们删除。
登录后发布评论

“ZooKeeper特性与节点数据类型详解”的评论:

还没有评论
关于作者
...
overfit同步小助手
文章同步
相关阅读

解密.bixi、.baxia勒索病毒：如何安全恢复被加密数据

基于密码的大模型安全治理的思考

win11系统安装虚拟机VMmare pro和ubuntu20.04

Jmeter和Postman那个工具更适合做接口测试？_intitle postman是自动化工具吗

VS Code 仅仅修改【左侧资源管理器】的字体大小

鸿蒙ArkTS页面如何与H5页面交互？

Zookeeper Watcher机制原理与代码实例讲解

文章导航