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中，可以使用stat或ls2命令查看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通过 [schemepermissions] 来构成权限列表：
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.curatorgroupId>
    <artifactId>curator-frameworkartifactId>
    <version>4.2.0version>
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单机模式启动流程源码分析