【Zookeeper】基本使用：必须知道的几个概念

1.数据模型

zookeeper 的视图结构和标准的文件系统非常类似，每一个节点称之为ZNode， 是zookeeper的最小单元。每个znode 上都可以保存数据以及挂载子节点。构成一个层次化的树形 。

每个节点的唯一标识就是它的路径，比如上面最左下方的节点的标识就为java节点的唯一标识就是/程序员/后端/JAVA。

那这些节点可以划分出什么类型吗？

划分节点类型的两个维度：能否持久化 + 节点序号是否有序（类似mysql的auto_increment），默认无序

• 持久节点（PERSISTENT）：客户端与zookeeper断开连接后，该节点依旧存在。每个节点都会为它的一级子节点维护一个顺序临时节点(EPHEMERAL)。
• 临时节点（EPHEMERAL） ：生命周期和客户端的会话绑定在一起，当客户端会话失效该节点自动清理。不能有子节点。
• 持久有序节点（PERSISTENT_SEQUENTIAL）：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号，顺序编号是一个单调递增的计时器，由父节点维护。
• 临时有序节点（EPHEMERAL_SEQUENTIAL）：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号，顺序编号是一个单调递增的计时器，由父节点维护。

后来又新增容器节点和两种TTL节点：

• 容器节点（CONTAINER） ：当子节点都被删除后，Container 也随即删除
• PERSISTENT_WITH_TTL ：超过TTL 未被修改，且没有子节点
• PERSISTENT_SEQUENTIAL_WITH_TTL
  • 客户端断开连接后不会自动删除Znode
  • 如果该Znode没有子Znode且在给定TTL时间内无修改，该Znode将会被删除；TTL单位是毫秒，必须大于 0且小于或等于 EphemeralType.MAX_TTL

注：同一级节点，名称不能相同

2.会话

1. Client初始化连接，状态转为CONNECTING(①)
2. Client与Server成功建立连接，状态转为CONNECTED(②)
3. Client丢失了与Server的连接或者没有接受到Server的响 应，状态转为CONNECTING(③)
4. Client 连上另外的 Server 或连接上了之前的 Server，状态 转为CONNECTED(②)
5. 若会话过期(是Server负责声明会话过期，而不是Client )， 状态转为CLOSED(⑤)，状态转为CLOSED
6. Client也可以主动关闭会话(④)，状态转为CLOSED

3.Stat 节点状态

每个节点除了存储数据内容以外，还存储了数据节点本身的一些状态信息，通过get命令可以获得状态信息的详细内容

上面状态属性的含义如下表：

4.写入校验（并发）

版本—>保证分布式数据原子性：zookeeper为数据节点引入了版本的概念，每个数据节点都有三类版本信息，对数据节点任何更新操作都会引起版本号的变化。

版本有点和我们经常使用的乐观锁类似。

• 悲观锁：是数据库中一种非常典型且非常严格的并发控制策 略。假如一个事务A正在对数据进行处理，那么在整个处理 过程中，都会将数据处于锁定状态，在这期间其他事务无法 对数据进行更新操作。
• 乐观锁：乐观锁和悲观锁正好想法，它假定多个事务在处理 过程中不会彼此影响，因此在事务处理过程中不需要进行加 锁处理，如果多个事务对同一数据做更改，那么在更新请求 提交之前，每个事务都会首先检查当前事务读取数据后，是 否有其他事务对数据进行了修改。如果有修改，则回滚事务 再回到zookeeper，version属性就是用来实现乐观锁机制的 “写入校验”

5.Watcher

zookeeper提供了分布式数据的发布/订阅功能，zookeeper 允许客户端向服务端注册一个 watcher 监听，当服务端的一 些指定事件触发了 watcher，那么服务端就会向客户端发送一个事件通知。

所有事件大致分为两类：当前节点事件 + 子节点事件

watcher 机制有一个特性：当数据发生改变的时候，那么 zookeeper会产生一个watch事件并发送到客户端，但是客户端只会收到一次这样的通知，如果以后这个数据再发生变化，那么之前设置 watch的客户端不会再次收到消息。因为 他是一次性的；如果要实现永久监听，可以通过循环注册来 实现