zookeeper学习总结（十四）

zookeeper学习总结（十四）

2021SC@SDUSC

前言

经过这一学期对zookeeper源码的学习，我对Znode(DataNode),Watcher,ACL等zookeeper中基本的概念有了较为深入的理解

Znode

zookeeper将数据存储在内存中，以此来实现高吞吐，减少访问延迟。而这些数据的载体就是Znode。

Znode，或者具体地，zookeeper源码中结点类为DataNode,是zookeeper中DataTree所维护的树形结构（这类似于文件系统）的一个单元。在DataTree中，我们用java的并发哈希表来维护路径与DataNode的关系。

每个DataNode节点上都会保存自己的数据和节点信息。一个节点相关的主要信息通过Stat的结构维护着。（Stat记录着一个结点创建时的事务ID，创建时的时间，最后一次更新时的事务ID，最后一次更新的时间等基本信息）

zookeeper服务端支持着7种节点类型，分别是：持久、持久顺序、临时、临时顺序、容器、持久 TTL、持久顺序TTL。

①持久、临时节点

持久是用的最多的一种类型也是默认的节点类型，临时节点相较于持久节点来说就是它会随着客户端会话结束而被删除，通常可以用在一些特定的场景，如分布式锁释放、健康检查等。

②持久顺序、临时顺序节点

持久顺序、临时顺序节点相对于持久、临时节点的特性就是zookeeper会自动在这两种节点之后增加一个数字的后缀，而路径 + 数字后缀是能保证唯一的，这数字后缀的应用场景可以实现诸如分布式队列，分布式公平锁等。

③容器节点

容器节点是 3.5 以后新增的节点类型，只要在调用create 方法时，指定CreateMode 为ConTAINER 即可创建容器的节点类型，容器节点的表现形式和持久节点是一样的，但是区别是zookeeper服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为 0 时，会自动删除该节点，除此之外和持久节点没有区别。
官方注释给出的使用场景是Container nodes are special purpose nodes useful for recipes such as leader, lock, etc. 说可以用在 leader 或者锁的场景中。

④持久TTL、持久顺序TTL节点

TTL 是time to live 的缩写，指带有存活时间，简单来说就是当该节点下面没有子节点的话，超过了TTL 指定时间后就会被自动删除，特性跟上面的容器节点很像，只是容器节点没有超时时间而已，但是TTL 启用是需要额外的配置，配置是zookeeper.extendedTypesEnabled 需要配置成true，否则的话创建TTL 时会收到Unimplemented 的报错。

Watcher

zookeeper中一个常用的功能是Watcher(事件监听器)，我们基于 zookeeper 上创建的节点，可以对这些节点绑定监听事件，比如可以监听节点数据变更、节点删除、子节点状态变更等事件，通过这个事件机制，可以基于 zookeeper实现分布式锁、集群管理等功能。

当数据发生变化的时候， zookeeper 会产生一个 watcher 事件，并且会发送到客户端。但是客户端只会收到一次通知。如果后续这个节点再次发生变化，那么之前设置 watcher 的客户端不会再次收到消息。（watcher 是一次性的 *** 作，这样的设计有效地减轻了服务端的压力）。 可以通过循环监听去达到永久监听效果。

WatcherEvent 是 zookeeper整个 Watcher 通知机制的最小通知单元，这个数据结构中只包含三部分内容：通知状态、事件类型和节点路径。也就是说，Watcher 通知非常简单，只会告诉客户端发生了事件，而不会说明事件的具体内容。例如针对 NodeDataChanged 事件，zookeeper的Watcher 只会通知客户端指定数据节点的数据内容发生了变更，而对于原始数据以及变更后的新数据都无法从这个事件中直接获取到，而是需要客户端主动重新去获取数据——这也是 zookeeper的 Watcher 机制的一个非常重要的特性。客户端向服务端注册 Watcher 的时候，并不会把客户端真实的 Watcher 对象传递到服务端，仅仅只是在客户端请求中使用 boolean 类型属性进行了标记，同时服务端也仅仅只是保存了当前连接的 ServerCnxn 对象。这样轻量级的 Watcher 机制设计，在网络开销和服务端内存开销上都是非常廉价的。

ACL

zookeeper采用ACL(Access Control Lists)策略来进行权限控制，类似于UNIX文件系统的权限控制。它定义了如下五种权限（perms）：

①CREATE ：允许创建子节点；

②READ ：允许从节点获取数据并列出其子节点；

③WRITE ：允许为节点设置数据；

④DELETE ：允许删除子节点；

⑤ADMIN ：允许为节点设置权限。

zookeeper默认提供了五种验证模式（scheme）：

①world: 它下面只有一个id, 叫anyone, world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的

②auth: 它不需要id, 只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)

③digest: 它对应的id为username:base64(SHA1(password))，它需要先通过username:password形式的authentication

④ip: 它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段

⑤super: 在这种scheme情况下，对应的id拥有超级权限，可以做任何事情(cdrwa---也就是上述五种权限)

收获

阅读zookeeper的源码，了解了zookeeper具体如何实现这些基本要素是一方面，更多的收获在于看到一个成熟项目是如何组织代码结构，如何有效解耦，划分模块；此外也看到了对Java这样一门面向对象语言，zookeeper是如何使用设计模式的（比如节点监听的观察者模式；又比如工厂模式：在创建 IWatchManager 时，会根据 zookeeper.watchManagerName 的配置去选择服务端的 watch 管理实现…）