Zookeeper节点及客户端基本操作

上篇相关博文:Zookeeper入门及单机及集群环境搭建

1.标题Zookeeper节点

1.1 节点类型

zookeeper节点默认大小是1M。

  • PERSISTENT 持久化节点: 所谓持久节点,是指在节点创建后,就一直存在,直到 有删除操作来主动清除这个节点。否则不会因为创建该节点的客户端会话失效而消失。

  • PERSISTENT_SEQUENTIAL 持久顺序节点:这类节点的基本特性和上面的节点类 型是一致的。额外的特性是,在 ZK 中,每个父节点会为他的第一级子节点维护一份时序, 会记录每个子节点创建的先后顺序。基于这个特性,在创建子节点的时候,可以设置这个属 性,那么在创建节点过程中,ZK 会自动为给定节点名加上一个数字后缀,作为新的节点名。 这个数字后缀的范围是整型的最大值。 在创建节点的时候只需要传入节点 “/test_”,这样 之后,zookeeper 自动会给”test_”后面补充数字。

  • EPHEMERAL 临时节点:和持久节点不同的是,临时节点的生命周期和客户端会 话绑定。也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉。注意,这里提 到的是会话失效,而非连接断开。另外,在临时节点下面不能创建子节点。 这里还要注意一件事,就是当你客户端会话失效后,所产生的节点也不是一下子就消失 了,也要过一段时间,大概是 10 秒以内,可以试一下,本机操作生成节点,在服务器端用 命令来查看当前的节点数目,你会发现客户端已经 stop,但是产生的节点还在。

  • EPHEMERAL_SEQUENTIAL 临时自动编号节点:此节点是属于临时节点,不过带 有顺序,客户端会话结束节点就消失。

1.2 ZooKeeper的stat结构

ZooKeeper命名空间中的每个znode都有一个与之关联的stat结构,类似于Unix/Linux文件系统中文件的stat结构。 znode的stat结构中的字段显示如下,各自的含义如下(官方文档:http://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_zkStatStructure):

cZxid:创建znode的事务ID。
mZxid:最后修改znode的事务ID。
pZxid:用于添加或删除子节点的znode的事务ID。
ctime:表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode创建时间。
mtime:表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode最近修改时间。
dataVersion:表示对该znode的数据的更改次数。
cversion:表示对此znode的子节点的更改次数。
aclVersion:表示对此znode的ACL更改的次数。
ephemeralOwner:如果znode是ephemeral(临时)类型节点,则这是znode所有者的 session ID。 如果znode不是ephemeral节点,则该字段设置为零。
dataLength:znode数据字段的长度。
numChildren:表示znode的子节点的数量。
在ZooKeeper Java shell中,可以使用statls2命令查看znode的stat结构。
如:stat /zk 或者 ls2 /zk
注: zxid,也就是事务id, 为了保证事务的顺序一致性,zookeeper 采用了递增的事 务 id 号(zxid)来标识事务。所有的提议(proposal)都 在被提出的时候加上了 zxid。实现中 zxid 是一个 64 位的 数字,它高32位是epoch(ZAB协议通过epoch编号来 区分 Leader 周期变化的策略)用来标识 leader 关系是否 改变,每次一个 leader 被选出来,它都会有一个新的 epoch=(原来的epoch+1),标识当前属于那个leader的 统治时期。低32位用于递增计数,高32位epoch变化时,低32位重新计数。

1.3 ZooKeeper Watch触发器

Zookeeper可以为所有的读操作设置watch,这些读操作包括:exists()、getChildren()和getData()。watch事件是一次性的触发器,当watch的对象状态发生改变时,将会触发此对象watch所对应的事件。watch事件将被异步地发送给客户端,并且Zookeeper为watch机制提供了有序的一致性保护。理论上,客户端接收watch事件的时间快于其看到watch对象状态变化的时间。官方:http://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#ch_zkWatches
Zookeeper所管理的watch可以分为两类:
数据watch(data watches):getData和exists负责设置数据watch
孩子watch(child watches):getChildren负责设置孩子watch
在这里插入图片描述
exists操作上的watch,在被监视的Znode创建、删除或数据更新时被触发。
getData操作上的watch,在背监视的Znode删除或数据更新时被触发。在被创建时不能被触发,因为只有一个Znode存在,getData操作时才会成功。
getChildren操作上的watch,在被监视的Znode的子节点创建或删除,或是这个Znode自身被删除时被触发。可以通过查看watch事件类型来区分是Znode,还是他的子节点被删除:NodeDelete表示Znode被删除,NodeDeletedChanged表示子节点被删除。
ZooKeeper 的 Watcher 具有以下几个特性:

  • 一次性触发器
    无论是服务端还是客户端,一旦一个 Watcher 被触发,ZooKeeper 都会将其从相应的存储中移除。因此,在 Watcher 的使用上,需要反复注册。这样的设计有效地减轻了服务端的压力。

  • 客户端串行执行
    Watch事件是异步发送到Client。Zookeeper可以保证客户端发送过去的更新顺序是有序的。例如:某个Znode没有设置watcher,那么客户端对这个Znode设置Watcher发送到集群之前,该客户端是感知不到该Znode任何的改变情况的。

  • 轻量
    WatcherEvent 是 ZooKeeper 整个 Watcher 通知机制的最小通知单元,这个数据结构中只包含三部分内容:通知状态、事件类型和节点路径。也就是说,Watcher 通知非常简单,只会告诉客户端发生了事件,而不会说明事件的具体内容。

2. 常用命令

创建节点

-s 表示是顺序节点
-e 标识是临时节点
path 节点路径
data 节点数据
acl 节点权限
注:临时节点在客户端结束与服务器的会话后,自动消失

create [-s] [-e] path data acl
修改节点数据内容
#如果指定版本,需要和当前节点的数据版本一致
set path data [version] :

######列出子节点

ls path
删除节点
#如果有子节点要先删除子节点
delete path [version] 
#删除当前路径节点及其所有子节点
rmr path 
设置节点配额

-n 是限制子节点个数 -b是限制节点数据长度。超出配额后,ZooKeeper不会报错,而是在日志信息中记录

#设置配额
setquota -n|-b val path 
#查看配额
listquota path
#删除配额
delquota [-n|-b] path 

3. ACL权限控制

3.1 ACL概述

ZooKeeper使用ACL来控制访问其znode(ZooKeeper的数据树的数据节点)。ACL的实现方式非常类似于UNIX文件的访问权限:它采用访问权限位 允许/禁止 对节点的各种操作以及能进行操作的范围。不同于UNIX权限的是,ZooKeeper的节点不局限于 用户(文件的拥有者),组和其他人(其它)这三个标准范围。ZooKeeper不具有znode的拥有者的概念。相反,ACL指定id集以及与之对应的权限。zookeeper对权限的控制是znode级别的,不具有继承性,即子节点不继承父节点的权限。
ACL是Access control lists 的缩写,也就是权限控制列表:针对节点可以设置相关读写等权限,目的是为了保障数据安全性;权限permissions可以指定不同的权限范围以及角色。
官方:http://zookeeper.apache.org/doc/current/zookeeperProgrammers.html#sc_ACLPermissions

3.2 ACL的构成

zookeeper的acl通过 [scheme🆔permissions] 来构成权限列表:
scheme:代表采用的某种权限机制;
id:代表允许访问的用户;
permissions:权限组合字符串。

acl的构成-scheme有以下几种类型:

  • world:world下只有一个id,即只有一个用户,也就是anyone,那么组合的写法就是 world:anyone:[permissions]
  • ip:当设置为ip指定的ip地址,此时限制ip进行访问,比如ip:192.168.77.130:[permissions]
  • auth:代表认证登录,需要注册用户获取权限后才可以登录访问,形式为 auth:userpassword:[permissions]
  • digest:需要对密码加密才能访问,组合形式为:digest:username:BASE64(SHA1(password)):[permissions]
    auth与digest的区别就是,前者使用明文密码进行登录,后者使用密文密码进行登录。setAcl /path auth:qqxhb:12345:cdrwa 与 setAcl /path digest:qqxhb:BASE64(SHA1(12345)):cdrwa是等价的,在通过 addauth digest qqxhb:12345 后都能操作指定节点的权限。在实际情况中,digest要更为常用一些。
  • super:代表超级管理员,拥有所有的权限

acl的permissions权限字符串缩写 crdwa :1)CREATE:创建子节点权限;2)READ:访问节点/子节点权限;3)WRITE:设置节点数据权限;4)DELETE:删除子节点权限;5)ADMIN:管理员权限。
acl命令:1)getAcl 获取某个节点的acl权限信息;2)setAcl 设置某个节点的acl权限信息;3)addauth 输入认证授权信息,注册时输入明文密码(登录),但是在zk的系统里,密码是以加密后的形式存在的。详细的操作可参考:zookeeper权限acl与四字命令

4. Zookeeper客户端

zookeeper的常用客户端有3种,分别是:zookeeper原生的、Apache Curator、开源的zkclient,由于Apache Curator是其中比较完美的ZooKeeper客户端,所以主要介绍Curator的特性。

  • zookeeper自带的客户端是官方提供的,比较底层、使用起来写代码麻烦、不够直接。
  • Apache Curator是Apache的开源项目,封装了zookeeper自带的客户端,使用相对简便,易于使用。
  • zkclient是另一个开源的ZooKeeper客户端,其地址:https://github.com/adyliu/zkclient生产环境不推荐使用。

4.1 Curator客户端

Curator Maven仓库

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-framework</artifactId>
    <version>4.2.0</version>
</dependency>

Curator几个组成部分

1.Client: 是ZooKeeper客户端的一个替代品, 提供了一些底层处理和相关的工具方法;
2.Framework: 用来简化ZooKeeper高级功能的使用, 并增加了一些新的功能, 比如管理到ZooKeeper集群的连接, 重试处理;
3.Recipes: 实现了通用ZooKeeper的recipe, 该组件建立在Framework的基础之上;
4.Utilities:各种ZooKeeper的工具类;
5.Errors: 异常处理, 连接, 恢复等;
6.Extensions: recipe扩展。

Curator主要解决了三类问题

1.封装ZooKeeper client与ZooKeeper server之间的连接处理;
2.提供了一套Fluent风格的操作API;
3.提供ZooKeeper各种应用场景(recipe, 比如共享锁服务, 集群领导选举机制)的抽象封装。

Curator主要从以下几个方面降低了zk使用的复杂性

1.重试机制:提供可插拔的重试机制, 它将给捕获所有可恢复的异常配置一个重试策略,并且内部也提供了几种标准的重试策略(比如指数补偿)
2.连接状态监控: Curator初始化之后会一直的对zk连接进行监听, 一旦发现连接状态发生变化, 将作出相应的处理
3.zk客户端实例管理:Curator对zk客户端到server集群连接进行管理.并在需要的情况, 重建zk实例,保证与zk集群的可靠连接
4.各种使用场景支持:Curator实现zk支持的大部分使用场景支持(甚至包括zk自身不支持的场景),这些实现都遵循了zk的最佳实践,并考虑了各种极端情况

Curator声称的一些亮点

1)内部采用SLF4J 来输出日志;2)采用驱动器(driver)机制, 允许扩展和定制日志和跟踪处理;3)提供了一个TracerDriver接口, 通过实现addTrace()和addCount()接口来集成用户自己的跟踪框架。
Curator的基本操作及API请参考后续:Zookeeper客户端Curator的基本操作、分布式锁及领导者选举示例

下篇博文:Zookeeper集群模式下领导者选举原理源码分析Zookeeper单机模式启动流程源码分析

©️2020 CSDN 皮肤主题: 创作都市 设计师:CSDN官方博客 返回首页