Zookeeper简介

特点

数据结构简单，类似Unix文件系统树形结构，每个目录称为Znode节点，但是又不同于文件系统，既可以做目录拥有子节点，又可以做文件存放数据。
1、同节点下的子节点名称不能相同
2、命名有规范
3、绝对路径
4、存放的数据大小有限制

数据模型

层次名称空间

1、类似unix文件系统，以 / 为根
2、区别：节点可以包含与之关联的数据以及子节点 (既是文件也是文件夹)
3、节点的路径总是表示为规范的、绝对的、斜杠分隔的路径。

znode

1、名称唯一，命名规范
2、节点类型：持久、顺序、临时、临时顺序
3、节点数据构成

znode 命名规范

1、null字符(\u0000)不能作为路径名的一部分；
2、以下字符不能使用，因为它们不能很好地显示，或者以令人困惑的方式呈现:
\u0001 - \u0019和\u007F - \u009F。
3、不允许使用以下字符:\ud800 - uf8fff， \uFFF0 - uFFFF。
4、“.”字符可以用作另一个名称的一部分，但是“.”和“..”不能单独用于指示路径上的节点，因为ZooKeeper不使用相对路径。下列内容无效:
“/a/b/. / c”或“c / a / b / . . /”。
5、“zookeeper”是保留节点名。

操作指令

多种方式保持有序

zxid

ZooKeeper中的每次更改操作都对应一个唯一的事务id，称为Zxid，它是一个全局有序的戳记，
如果zxid1小于zxid2，则zxid1发生在zxid2之前。

Version numbers

版本号，对节点的每次更改都会导致该节点的版本号之一增加。这三个版本号是dataVersion
(对znode数据的更改次数)、cversion(对znode子节点的更改次数)和aclVersion(对znode ACL的更改次数)。

Ticks

当使用多服务器ZooKeeper时，服务器使用“滴答”来定义事件的时间，如状态上传、会话超时、
对等点之间的连接超时等。滴答时间仅通过最小会话超时(滴答时间的2倍)间接公开;如果客户端请求的会话超时
小于最小会话超时，服务器将告诉客户端会话超时实际上是最小会话超时。

Real time

ZooKeeper除了在znode创建和修改时将时间戳放入stat结构之外，根本不使用Real time或时钟时间。

节点上的元数据信息-Stat

可快速的搭建集群 可复制

快速

ZooKeeper数据加载在内存中，这意味着ZooKeeper可以获得高吞吐量和低延迟数。
以读取为主的工作负载中，它尤其快。
操作的Znode的数据大小限制1M。

zookeeper 会话机制

1、一个客户端连接一个会话，由zk分配唯一会话id；
2、客户端以特定的时间间隔发送心跳以保持会话有效； tickTime
3、超过会话超时时间未收到客户端的心跳，则判定客户端死了；(默认2倍tickTime)
4、会话中的请求按FIFO顺序执行。

znode 数据构成

1、节点数据：存储的协调数据（状态信息、配置、位置信息等）
2、节点元数据（stat结构）
3、数据大小上限：1M

znode 节点类型

1、持久节点
2、顺序节点
3、临时节点
4、临时顺序节点

watch监听机制

两类watch
1、data watch 监听 数据变更
2、child watch 监听子节点变化

watch事件

Created event:
Enabled with a call to exists.
Deleted event:
Enabled with a call to exists, getData, and getChildren.
Changed event:
Enabled with a call to exists and getData.
Child event:
Enabled with a call to getChildren.

特性

1、一次性触发：watch触发后即被删除。要持续监控变化，则需要持续设置watch；
2、有序性：客户端先得到watch通知，后才会看到变化结果

1、watch是一次性触发器;如果您获得了一个watch事件，并且希望得到关于未来更改的通知，则必须设置另一个watch。
2、因为watch是一次性触发器，并且在获取事件和发送获取watch的新请求之间存在延迟，所以不能可靠地得到节点发生的每个更改。
3、一个watch对象只会被特定的通知触发一次。如果一个watch对象同时注册了exists、getData，当节点被删除时，删除事件对exists 、getData都有效，但只会调用watch一次。

附录

分布式锁以及分布式队列的实现