zookeeper数据结构、通知

Dear 丶 2022-02-16 15:43 242阅读 0赞

ZooKeeper提供的名称空间非常类似于标准文件系统。名称是由斜线（/）分隔的一系列路径元素。ZooKeeper名称空间中的每个节点都由一个路径标识。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]

树是由节点所组成，zookeeper的数据存储也同样是基于节点，这个节点叫做Znode.但是，不同于树的节点，Znode的引用方式是路径引用，类似于文件路径：/app1/p\_1

这样的层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样对不同信息作出清晰的隔离。

### **ZooKeeper中节点** ###

ZooKeeper的节点是通过像树一样的结构来进行维护的，并且每一个节点通过路径来标示以及访问。除此之外，每一个节点还拥有自身的一些信息，包括：数据、数据长度、创建时间、修改时间等等。从这样一类既含有数据，又作为路径表标示的节点的特点中，可以看出，ZooKeeper的节点既可以被看做是一个文件，又可以被看做是一个目录，它同时具有二者的特点。为了便于表达，今后我们将使用Znode来表示所讨论的ZooKeeper节点。

具体地说，Znode维护着数据、ACL（access control list，访问控制列表）、时间戳等交换版本号等数据结构，它通过对这些数据的管理来让缓存生效并且令协调更新。每当Znode中的数据更新后它所维护的版本号将增加，这非常类似于数据库中计数器时间戳的操作方式。

另外Znode还具有原子性操作的特点：命名空间中，每一个Znode的数据将被原子地读写。读操作将读取与Znode相关的所有数据，写操作将替换掉所有的数据。除此之外，每一个节点都有一个访问控制列表，这个访问控制列表规定了用户操作的权限。

ZooKeeper中的节点有两种，分别为**临时节点**和**永久节点**。节点的类型在创建时即被确定，并且不能改变。

*  **① 临时节点：**该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。**另外，ZooKeeper的临时节点不允许拥有子节点。**
 *  **② 永久节点：**该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
 *  **顺序节点**：当创建Znode的时候，用户可以请求在ZooKeeper的路径结尾添加一个**递增的计数**。这个计数**对于此节点的父节点来说**是唯一的，它的格式为"%10d"(10位数字，没有数值的数位用0补充，例如"0000000001")。当计数值大于2^32-1时，计数器将溢出。

### **Znode:** ###

znode包含了数据、子节点引用、访问权限等等。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1][]

*  **data：**Znode存储的数据信息。
 *  **ACL：**记录Znode的访问权限，即哪些人或哪些IP可以访问本节点。
 *  **stat：**包含Znode的各种元数据，比如事务ID、版本号、时间戳、大小等等。
 *  **child：**当前节点的子节点引用，类似于二叉树的左孩子右孩子。

ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来**管理调度数据**，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并**限制每个Znode的数据大小至多1M**，但常规使用中应该远小于此值。

### **ZooKeeper中的时间**  ###

ZooKeeper有多种记录时间的形式，其中包含以下几个主要属性：

**(1) Zxid**

致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，也就是说，每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际 上，ZooKeeper的每个节点维护者三个Zxid值，为别为：cZxid、mZxid、pZxid。

*  **①** **cZxid**： 是节点的创建时间所对应的Zxid格式时间戳。
 *  **② mZxid**：是节点的修改时间所对应的Zxid格式时间戳。

实现中Zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个**递增计数**。

**(2) 版本号 (乐观锁)**

对节点的每一个操作都将致使这个节点的版本号增加。每个节点维护着三个版本号，他们分别为：

*  **① version**：节点数据版本号
 *  **② cversion**：子节点版本号
 *  **③ aversion**：节点所拥有的ACL版本号

### **ZooKeeper节点属性** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2][]

### **ZooKeeper服务中操作**   ###

![2019042309285530.png][]

更新ZooKeeper操作是有限制的。delete或setData必须明确要更新的Znode的版本号，我们可以调用exists找到。如果版本号不匹配，更新将会失败。

更新ZooKeeper操作是非阻塞式的。因此客户端如果失去了一个更新(由于另一个进程在同时更新这个Znode)，他可以在不阻塞其他进程执行的情况下，选择重新尝试或进行其他操作。

尽管ZooKeeper可以被看做是一个文件系统，但是处于便利，摒弃了一些文件系统地操作原语。因为文件非常的小并且使整体读写的，所以不需要打开、关闭或是寻地的操作。

# **zookeeper的命令操作** #

## **1. create \[-s\] \[-e\] path data acl** ##

*  \-s 表示节点是否有序
 *  \-e 表示是否为临时节点
 *  默认情况下，是持久化节点

## **2. get path \[watch\]** ##

*  获得指定 path的信息

## **3.set path data \[version\]** ##

*  修改节点 path对应的data
 *  乐观锁的概念
 *  数据库里面有一个 version 字段去控制数据行的版本号

## **4.delete path \[version\]** ##

*  删除节点

# **stat信息** #

*  cversion = 0       子节点的版本号
 *  aclVersion = 0     表示acl的版本号，修改节点权限
 *  dataVersion = 1    表示的是当前节点数据的版本号
 *  czxid    节点被创建时的事务ID
 *  mzxid   节点最后一次被更新的事务ID
 *  pzxid    当前节点下的子节点最后一次被修改时的事务ID
 *  ctime = Sat Aug 05 20:48:26 CST 2017
 *  mtime = Sat Aug 05 20:48:50 CST 2017
 *  ephemeralOwner = 0x0   创建临时节点的时候，会有一个sessionId 。 该值存储的就是这个sessionid
 *  dataLength = 3    数据值长度
 *  numChildren = 0  子节点数

## ZooKeeper会话（session） ##

使用客户端来创建一个和zk服务端连接的句柄，这就是一个会话（session）。Session一旦建立，状态就是连接中（CONNECTING）状态，然后客户端会尝试去连接zk服务端，连接成功之后状态变成已连接（CONNECTED）。一般正常情况下只会有这两个状态。不过，还是会发生一些无法恢复的错误/故障，比如：session过期，认证失败，或者客户端关闭连接，这种情况下，session状态会变成关闭（CLOSED）状态。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 3][]

当一个session建立的时候，zk服务端会生成一个64位的数字，也就是这个session的标识（姑且称之为session id吧），zk客户端会保存这个标识。如果zk客户端因为某种原因连接到了另一个zk服务端，他会把这个session id传给新的服务端。出于安全考虑，zk服务端在创建连接时，不仅仅生成一个session id，还会同时传给zk客户端一个密码，这个session id+密码是可以被任何一个zk服务端校验的。这样，每次zk客户端重连zk服务端的时候，会同时传递session id+密码，zk服务端校验通过了才会建立连接。

# Watcher（ 数据变更的通知） #

ZooKeeper提供了分布式数据的**发布/订阅**功能。一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能够让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。在ZooKeeper中，引入了Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些指定事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

整个Watcher注册与通知过程如下图所示。

![20190422214540904.png][]

从上图中，我们可以看到，ZooKeeper的Watcher机制主要包括客户端线程、客户端WatchManager和ZooKeeper服务器三部分。在具体工作流程上，简单地讲，客户端在向ZooKeeper服务器注册Watcher的同时，会将Watcher对象存储在客户端的WatchManager中。当ZooKeeper服务器端触发Watcher事件后，会向客户端发送通知，客户端线程从WatchManager中取出对应的Watcher对象来执行回调逻辑。

参考：[https://blog.csdn.net/u011499747/article/details/78024329][https_blog.csdn.net_u011499747_article_details_78024329]

[https://www.cnblogs.com/wuxl360/p/5817471.html][https_www.cnblogs.com_wuxl360_p_5817471.html]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20220216/cc8ae4a025d3413b95a6cace8ecfa23d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1]: /images/20220216/26cf779372bc48e5806259ac890ad011.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2]: /images/20220216/4e6333eb590b4385b8b5a4661b12e5e4.png
[2019042309285530.png]: /images/20220216/e7b47352cb43489983bb15c34d0a7d4f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 3]: /images/20220216/7a85baf9333d46fbb98b9cf892d28034.png
[20190422214540904.png]: /images/20220216/20d256d962c14a20b5e2d3eb893ee273.png
[https_blog.csdn.net_u011499747_article_details_78024329]: https://blog.csdn.net/u011499747/article/details/78024329
[https_www.cnblogs.com_wuxl360_p_5817471.html]: https://www.cnblogs.com/wuxl360/p/5817471.html