Zookeeper使用篇-Zookeeper系统核心模型，百度java面试经验

ctime

ctime代表Create time，与czxid搭配使用，即在创建当前节点的时候，记录创建的时间

mtime

mtime代表Modified time，与mzxid搭配使用，即会记录最后一次节点变更操作的时间

version

version代表当前节点的版本号

cversion

cversion代表当前节点中创建的子节点的版本号

aversion

aversion代表当前节点中ACL权限相关的版本号

ephemeralOwner

ephemeralOwner用来保存创建节点的时候生成的会话sessionId，如果当前节点是持久化节点，这个值一般为0（0x0）

dataLength

dataLength保存了当前节点中存储的数据对应的字节长度

numChildren

numChildren中保存了当前节点中创建的子节点的个数

pzxid

pzxid保存了该节点的子节点列表中最后一次被修改的时候生成的事务ID，需要注意的是这里只有子节点列表变化才会重新生成pzxid，如果某个子节点内容修改等操作并不会生成新的pzxid

节点的版本控制

从stat类的定义中，我们看到，在ZNode中，存在多种事务操作的ID，但是zk是如何保证每次事务操作的正确性和稳定的呢？这个时候我们不禁要考虑分布式场景下一个概念–锁，在分布式系统中，一般事务操作，都要保证排他性，而主流的锁方案分为悲观锁和乐观锁两种。悲观锁具有强烈的独占和排他性，但是整个处理过程中，数据会完全被锁定，其他的事务对该数据将做不了任何操作，哪怕是读取数据的操作，直到事务操作结束释放悲观锁为止。但是在分布式场景下，更多的操作是读取共享的数据，如果使用悲观锁，则会造成大量的数据被锁定，造成性能大幅度下降。因此乐观锁的概念出现，在乐观锁中的绝大多数操作都是不对数据加锁的，而是在更新操作之前，去检查当前事务读取的数据与即将要修改的数据是否一致，从而确定是否在读取完数据到更新数据之前的过程中，有木有别的事务对该数据进行了修改操作。如果发现已经被更新了，则回滚当前事务操作，如果没有修改则执行当前的事务。在JDK中，乐观锁的一个典型实现则是利用CAS理论实现的，而Zookeeper也基于类似的实现方案，在每次事务操作之前，都会在 PrepRequestProcessor处理器中的 setData数据更新操作之前，进行一次版本检查操作，如下:

1. int newVersion = checkAndIncVersion(nodeRecord.stat.getVersion(), setDataRequest.getVersion(), path);

checkAndIncVersion方法如下:

1. privatestaticint checkAndIncVersion(int currentVersion, int expectedVersion, String path)

2. throwsKeeperException.BadVersionException{

3. //判断当前请求的版本不是-1，并且与原来的版本号不同时，则抛出异常，其他情况下则将版本号+1

4. if(expectedVersion != -1&& expectedVersion != currentVersion) {

5. thrownewKeeperException.BadVersionException(path);

6. }

7. return currentVersion + 1;

8. }

通知机制Watcher

在前面的文章中，我们学习了Zookeeper的发布订阅功能的实践，同时我们也知道zk中存在多种监听通知，可以实现一对一，一对多等不同的通知机制。而zk中的watcher注册和通知过程如下:

从这我们可以看出，整个Watcher机制中，主要包括watcherManager、客户端线程以及Zookeeper服务端三部分。大概的过程为客户端在朝服务器注册Watcher的同时，将watcher对象存储在客户端的WatcherManager中。当Zookeeper服务端触发了Watcher事件后，会向客户端发送通知，客户端线程则是从WatcherManager中取出Watcher对象来执行对应的逻辑。

Watcher接口

在Zookeeper中，Watcher接口表示一个标准的事件处理器。定义了对应的逻辑，其中KeeperState和EventType两个枚举类型的属性分别代表了通知的状态以及通知的事件类型，并且在Watcher接口中，定义了一个方法作为触发通知以后的逻辑处理方法:

process(WatchedEventevent)，接下来我们来看看这两个核心的枚举类及其参数

KeeperState

KeeperState定义了Watcher事件的所有状态类型，代码如下:

1. publicenumKeeperState{

2. @Deprecated

3. Unknown(-1), //未知状态，已经废弃

4. Disconnected(0),//断开连接

5. @Deprecated

6. NoSyncConnected(1),//没有连接，已经废弃

7. SyncConnected(3),//已经连接

8. AuthFailed(4),//权限异常

9. ConnectedReadOnly(5),//当前连接仅仅支持读操作

10. SaslAuthenticated(6),

11. Expired(-112),

12. Closed(7);//关闭连接

13. .........................

14. }

EventType

除了KeeperState以外，EventType代表了通知的类型，代码如下:

1. publicenumEventType{

2. None(-1),//未知

3. NodeCreated(1),//创建节点成功通知

4. NodeDeleted(2),//节点移除通知

5. NodeDataChanged(3),//当前节点数据变化通知

6. NodeChildrenChanged(4),//子节点列表变化通知

7. DataWatchRemoved(5),

8. ChildWatchRemoved(6);

9. }

而在Zookeeper开发过程中，往往是两种类型参数组合返回，我们将常见的场景通知和组合列成表格，大概如下:

KeeperState	EventType	触发场景
SyncConnected	None	建立连接成功
NodeCreated	节点被创建
NodeDeleted	节点被删除
NodeDataChanged	节点内容变化
NodeChild renChanged	节点所属子节点列表变化
Disconnected	None	断开连接
Expired	None	超时
AuthFailed	None	1.错误的Scheme进行权限检查 2.SASL权限检查失败

ACL权限操作

在Zookeeper中，提供了ACL权限机制来保障节点及对应数据的安全，但是需要注意的是Zookeeper中的ACL机制和传统的ACL并不一样，分别分为：权限模式(Scheme)、授权对象(ID)和权限(Permission)，通常是以Scheme:ID:Permission方式组合成一个有效的ACL信息。接下来我们具体的学习这三种组成模块：

权限模式—Scheme

权限模式在Zookeeper中来确定权限验证过程中的校验策略。常见的策略有四种:

IP

IP模式一般通过IP地址进行粗粒度的权限控制，例如"ip:192.168.1.1/24"代表是192.168.1.*这个网段的IP进行的权限控制。

Digest

Digest是使用最多的一种权限模式，基于传统的"username:password"模式来控制对应的权限，当我们使用Digest方式来验证权限的时候，Zookeeper中先后两次进行编码处理，分别是SHA-1和BASE64算法，加密过程的实现在 DigestAuthenticationProvider类的

generateDigest(StringidPassword)方法中进行封装

World

World模式属于一种开放的权限模式，此模式下几乎没有任何权限控制，所有用户都可以随意对任何节点进行操作

Super

在Zookeeper中存在一个超级管理员的模式，此模式不需要主动设置，在任何其他的权限策略下都可以使用，称之为Super权限，一旦获取了Super权限，即拥有了超级管理员权限，可以对所有的节点进行任意操作。

授权对象–ID

授权对象指的是权限所在的用户或者指定的权限实体，而在不同的模式下，授权对象都是不同的，各个权限模式与授权对象的关系如下:

权限模式	授权对象
IP	通常是一个ip或者一个ip段，例如192.168.1.1
Digest	自定义的，一般为"username:password"
World	anyone
Super	与Digest一样，需要指定一个超级管理员信息

权限–Permission

权限即指的是经过权限模式认证后

《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》

【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享

的被允许的操作，在Zookeeper中，权限操作分为五大类:

• Create©：数据节点的创建权限，并且允许创建子节点

• Delete(D)：允许删除该节点的子节点

• Read®：允许对该数据节点进行读取，也可以获取子节点列表、读取子节点等

• Write(W)：数据节点的更新权限，允许对该节点内容修改

• Admin(A)：数据节点的管理权限，允许对其设置ACL权限操作

实现自定义权限控制器

一般开发中，Zookeeper自带的权限操作已经满足日常使用，但是如果需要特殊的权限控制操作，Zookeeper同样支持自定义一个权限控制器，在Zookeeper中，权限主要在org.apache.zookeeper. server.auth.AuthenticationProvider接口中定义，其代码定义如下:

1. publicinterfaceAuthenticationProvider{

2. String getScheme();

3. KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte authData[]);

4. boolean matches(String id, String aclExpr);

5. boolean isAuthenticated();

6. boolean isValid(String id);

7. }

我们需要实现自定义的权限控制器只要实现当前接口，在实现完毕以后，我们将该自定义的权限控制器注册到Zookeeper服务中去，而注册的方式有两种：

1.系统属性配置

在Zookeeper启动的时候，在启动参数中指定:

1. -Dzookeeper.authProvider.l=xxx.MyauthProvider

2.配置文件方式

Zookeeper中的zoo.cfg配置文件中可以添加如下的配置:

1. authProvider.l=xxx.MyauthProvider

Super模式使用

在Zookeeper使用过程中，往往存在一个场景，即原来节点的创建者设置了ACL权限，但是这个创建者已经不再使用了，而其他的客户端想要使用该节点，该怎么做呢？这个时候就需要Super模式的用户出马了！使用超级管理员权限，具体的步骤如下:

1.在Zookeeper启动的时候添加系统属性:

1. -Dzookeeper.DigestAuthenticationProvider. superDigest=root:kWN6aNSbjcKWPqjiV7c

2. gON24raU=

即指定了root用户拥有超级管理员权限，设置好以后启动Zookeeper，即可在客户端中使用了

2.编写客户端代码使用当前Super权限的管理员操作节点，例如:

1. publicclassAuthSample_Super{

2. fin a l sta tic String PATH = "/zk-book";

3. public sta tic void m ain(String[] args) throwsException{

4. ZooKeeper zookeeperl = newZooKeeper("domainl.book.zookeeper:2181",5000,

5. null);

6. zookeeperl.addAuthlnfo("digest", "root:tru e".getBytes());

7. zookeeperl.create( PATH, "init".getBytes(), Ids.CREATORALLACL, CreateMode.EPHEMERAL );

8. ZooKeeper zookeeper2 = newZooKeeper("domainl.book.zookeeper:2181",50000,

9. n u ll);

10. zookeeper2.addAuthlnfo("digest", "root:zk-book".getBytes());

11. System.out.println(zookeeper2.getData(PATH, false, null));

12. ZooKeeper zookeeper3 = newZooKeeper("domainl.book. zookeeper:2181",50000,

13. n u ll);

14. zookeeper3.addAuthlnfo("digest", "root:false ". getBytes());

15. System.out.println(zookeeper3.getData(PATH,false,null));

16. }

17. }

运行以后，结果如下:

1. [B

2. org.apache.zookeeper.KeeperException$NoAuthException:

3. KeeperErrorCode= NoAuthfor/zk-book

可见root用户的确可以操作一个受限制的节点
eeper3.addAuthlnfo(“digest”, "root:false ". getBytes());`

15. System.out.println(zookeeper3.getData(PATH,false,null));

16. }

17. }

运行以后，结果如下:

1. [B

2. org.apache.zookeeper.KeeperException$NoAuthException:

3. KeeperErrorCode= NoAuthfor/zk-book

可见root用户的确可以操作一个受限制的节点