【Spring Cloud系统】- Zookeer特性与使用场景

旧城等待， 2023-10-16 18:17 142阅读 0赞

## 【Spring Cloud系统】- Zookeer特性与使用场景 ##

### 一、概述 ###

Zookeeper是一个分布式服务框架，是Apache Hadoop的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题。如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

> 简单来说zookeeper = 文件系统 + 监听通知机制

### 二、Zookeeper是什么 ###

1.  ZooKeeper是分布式协调服务的开源架构，可以用来解决分布式集群中应用系统的一致性问题（例如怎样避免同时操作同一数据造成脏读的问题）；也是为分布式程序提供协调服务的Apache项目。
2.  ZooKeeper本质上是一个分布式的小文件存储系统，提供基于类似于文件系统目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控你存储的数据的状态变化，通过监控数据状态的变化，从而可以达到基于数据的集群管理，诸如：统一命名服务、分布式配置管理、负载均衡、分布式锁、分布式协调等功能。

### 三、Zookeeper有哪些数据结构 ###

ZooKeeper可以理解一个文件系统，ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。

#### 3.1 数据结构图 ####

![在这里插入图片描述][9cff34361f66470da09f428422cf1973.png_pic_center]

如上图的每个节点称为一个Znode。每个Znode由3部分组成。

*  stat: 此为状态信息，描述该Znode的版本，权限等信息。
 *  data: 与该Znode关联的数据
 *  children: 该Znode下的子节点

#### 3.2 节点类型 ####

Znode有两种，分别为临时节点和永久节点。

节点的类型在创建时既被确定，并且不能改变。

**临时节点**：该节点的生命周期依赖于创建它们的会话，一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。

**永久节点**：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

Znode还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便于记录每个子节点创建的先后顺序。它的格式为"%10d"(10位数字，没有数值的数位用0补充，例如：“000000001”)。

因为有序列化属性，这样Zookeeper便有四种类型的Znode节点，分别对应：

*  PERSISTENT：永久节点
 *  EPHEMERAL：临时节点
 *  PERSISTENT\_SEQUENTIAL：永久节点、序列化
 *  EPHEMERAL\_SEQUENTIAL：临时节点、序列化

#### 3.3 节点类型 ####

每个znode都包含了一系列的属性，通过命令get，可以获得节点的属性。

*  dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。
 *  cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。
 *  cZxid ：Znode创建的事务id。
 *  mZxid ：Znode被修改的事务id，即每次对znode的修改都会更新mZxid。
    
    对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。
 *  ctime：节点创建时的时间戳。
 *  mtime：节点最新一次更新发生时的时间戳
 *  ephemeralOwner:如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果不是, ephemeralOwner值为0。
 *

### 四、Zookeeper有哪些核心功能 ###

#### 4.1 保证数据一致性 ####

保证数据的一致性有两种情况:

*  重新选取出leader后的数据同步。
 *  leader处理完事务请求后与follow保持数据一致。

##### 首先是重新选取出新leader后的数据同步 #####

通过FastLeaderElection选举算法选出leader，选出leader之后，leader需要与其他节点进行同步，当超过一半的follow与leader进行同步完成后，leader才能成为真正的leader,然后follow会带上自己最大的ZXID尝试与leader连接，来确定数据是否同步。

##### 其次是leader处理完成事务请求后与follow保持数据一致 #####

事务请求全部是由leader处理的，当leader收到请求后，会将事务请求转化为事务Proposal，由于leader会为每一个follow创建一个队列，所以leader会将事务放入响应队列中，按顺序处理事务请求，来保证事务的顺序性。之后会在队列中顺序向其他节点广播该提案。follow收到后会将其以事务的形式写入到本地日志中，并向leader发送反馈ack，leader会等待其他follow的回复，当收到一半以上的follow响应时，leader会向其他节点发送commit消息，同时leader提交该提案。当follow将数据同步完成之后，leader会将该follow加入到真正可用的follow列表中。

#### 4.2 更新和监听 ####

ZooKeeper支持watch的概念。客户端可以在znode上设置监视，当znode有事件发生时，通知给感兴趣的客户端。通知变化时收到通知。非常适用于保障分布式情况下的数据一致性。dubbo中使用zk作为注册中心等都用到了zk的更新监听功能。

### 五、Zookeeper有哪些权限控制 ###

ZooKeeper通过ACL权限控制列表来控制其对znode节点的访问权限。ACL权限与Unix文件系统中的权限控制类似，使用权限位限制指定角色对znode节点的各节点操作，下面详细介绍ZooKeeper中ACL权限控制。

#### 5.1 权限列表 ####

zookeeper中对znode节点的操作权限主要有以下五种，我们可以通过其**简写的任意组合**来实现对znode节点的不同权限控制。

<table> 
 <thead> 
  <tr> 
   <th>名称</th> 
   <th>简写</th> 
   <th>权限说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>CREATE</td> 
   <td>c</td> 
   <td>允许创建当前节点下的字节点</td> 
  </tr> 
  <tr> 
   <td>DELETE</td> 
   <td>d</td> 
   <td>允许删除当前节点下的子节点，仅限下一级</td> 
  </tr> 
  <tr> 
   <td>READ</td> 
   <td>r</td> 
   <td>允许读取节点数据以及显示子节点的列表</td> 
  </tr> 
  <tr> 
   <td>WRITE</td> 
   <td>w</td> 
   <td>允许设置当前节点的数据</td> 
  </tr> 
  <tr> 
   <td>ADMIN</td> 
   <td>a</td> 
   <td>管理员权限，允许设置或读取当前节点的权限列表</td> 
  </tr> 
 </tbody> 
</table>

#### 5.2 ACL权限特点 ####

Zookeeper权限控制有以下几个特点：

1.  zookeeper的权限是基于znode节点的，需要对每个节点设置权限。
2.  znode节点支持**同时设置多种权限方案和多个权限**。当znode有多种权限的时候，只要有一个权限允许当前操作，即可执行当前操作，即多个权限之间为**或的关系**。
3.  子节点不会继承父节点的权限，客户端没有权限访问当前节点，但是可以访问当前节点的子节点。
4.  使用setAcl命令对节点进行权限设置会覆盖掉原来的权限。

### 六、Zookeeper数据持久化 ###

ZooKeeper数据的组织形式为一个类似文件系统的数据结构，而这些数据都是存储在内存中的，所以我们可以认为，ZooKeeper是一个基于内存的小型数据库。

如果数据只存储在内存中的话，那么在ZooKeeper宕机或者断电的情况下，数据将会丢失，所以ZooKeeper也制定了一些数据持久方式：

*  事务日志log
 *  数据快照snapshot

#### 6.1 事务日志log文件 ####

针对每一次客户端的事务操作（写）,ZooKeeper都会将他们记录到事务日志中，当然，ZooKeeper也会将数据变更应用到内存数据库中，我们可以在ZooKeeper的主配置文件zoo.cfg中配置内存中的数据持久化目录，也就是事务日志存储路径dataLogDir。如果没有配置dataLogDir（非必填），事务日志将存储到dataDir（必须填）。

#### 6.2 事务日志log文件 ####

数据快照是ZooKeeper数据存储中另–个非常核心的运行机制。顾名思义，数据快照用来记录ZooKeeper服务器上某一个时刻的全量内存数据内容，并将其写入到指定的磁盘文件中。

文件存储：

快照文件存储在dataDir属性配置的目录下。

和事务日志文件的命名规则一致，快照数据文件也是使用ZXID的十六进制表示来作为文件名后缀，该后缀标识了本次数据快照开始时刻的服务器最新ZXID。这个十六进制的文件后缀非常重要，在数据恢复阶段，ZooKeeper会根据该ZXID来确定数据恢复的起始点。

和事务日志文件不同的是ZooKeeper的快照数据文件没有采用“预分配”机制，因此不会像事务日志文件那样内容中可能包含大量的“0”。每个快照数据文件中的所有内容都是有效的，因此该文件的大小在一定程度上能够反映当前ZooKeeper内存中全量数据的大小。

### 七、总结 ###

Zookeeper作为一个分布式协调服务，由于其通用性，所以在众多软件开发中被使用。它一般包括存储数据和监听功能，主要提供节点选举、统一配置文件管理、发布和订阅消息、集群管理等功能。在以后的博文中讲详细讲解每个部分详细使用。

[9cff34361f66470da09f428422cf1973.png_pic_center]: https://img-blog.csdnimg.cn/9cff34361f66470da09f428422cf1973.png#pic_center