zookeeper概述及应用场景
zookeeper的数据模型
zookeeper的数据结构
zookeeper的数据模型的结构与Unix文件系统很类似，整体上可以看作一棵树，每个节点称做一个ZNode，每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。
zookeeper的数据节点可以视为树状结构(或者目录)，树中的各节点被称为znode(即zookeeper node)，一个znode可以有多个子节点。
zookeeper节点在结构上表现为树状，使用路径path来定位某个znode。比如"/etc/sysconfig/network-scripts/ifcfg-eth0"，此处"/","etc","sysconfig","network-scripts","ifcfg-eth0"分别是根节点，一级节点，二级节点，三级节点和四级节点，其中"etc"是"sysconfig"的父节点，"sysconfig"是"etc"的子节点。
znode兼具文件和目录两种特点，既像文件一样维护着数据，元信息，ACL，时间戳等数据结构，又像目录一样可以作为路径标识的一部分。
znode的组成部分
一个znode大体上分为3个部分，如下所示:
- 节点的数据: 即znode data(节点path，节点data)的关系就像是python中dict的key，value的关系。
- 子节点: 即某个节点的子节点(children)。
- 节点的状态: 用来描述当前节点的创建，修改记录，包括cZxid，ctime等。
znode状态stat属性
在zookeeper shell中使用stat命令查看指定路径节点的状态信息，如下图所示。
属性说明如下:
cZxid: 数据节点创建时的事物ID。
ctime: 数据节点创建时的时间。
mZxid: 数据节点最后一次更新时的事物ID。
mtime: 数据节点最后一次更新时的时间。
pZxid: 数据节点的子节点最后一次被修改时的事务ID。
cversion: 子节点的更改次数。
dataVersion: 数据节点的更改次数，即维护的是一个数据版本号。
aclVersion: 节点的ACL的更改次数。
ephemeralOwner: 如果节点是临时节点，则表示创建该节点的会话SessionID，如果节点是持久节点，则该属性值为0。
dataLength: 数据内容的长度。
numChildren: 数据节点当前的子节点的数量。
znode的类型
持久(Persistent)
客户端和服务端断开连接后，创建的节点不删除。
其被细分为以下两类节点：
- 持久化目录节点: 客户端与zookeeper断开连接后，该节点依旧存在。
- 持久化顺序编号目录节点: 客户端与zookeeper断开连接后，该节点依旧存在，只是zookeeper给该节点名称进行顺序编号。
短暂(Ephemeral)
客户端和服务器端口连接后，创建的节点自动删除。
其被细分为以下两类节点：
- 临时目录节点: 客户端与zookeeper断开连接后，该节点被删除。
- 临时顺序编号目录节点: 客户端与zookeeper断开连接后，该节点被删除，只是zookeeper该该节点名称进行顺序编号。
温馨提示
- 创建znode时设置顺序表示，znode名称会附加一个值，顺序号是一个单调递增的计数器，由父节点维护。
- 在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序。
zookeeper事件监听机制
watcher概念
zookeeper提供了数据的"发布/订阅"功能，多个订阅者可同时监听某一特定主题对象，当该主题对象的自身状态发生变化时(如节点内容变更，节点下的子节点列表改变等)，会实时，主动通知所有订阅者。
zookeeper采用了Watch机制实现数据的"发布/订阅"功能。该机制在被订阅对象发生变化时会异步通知客户端，因此客户端不必在Watcher注册后轮询阻塞，从而减轻了客户端压力。
watch机制实际上与观察者模式类似，也可看作是一种观察者模式在分布式场景下的实现方式。
watch架构
watcher实现由三个部分组合:
- zookeeper服务端
- zookeeper客户端
- 客户端的ZKWatchManager对象
watcher发布订阅流程如下所示:
- 客户端首先将Watch注册到服务端，同时将Watch对象保存到客户端的Watch管理器中;
- 当zookeeper服务端监听的数据状态发生变化时，服务端会主动通知客户端;
- 接着客户端的Watch管理器会触发相关Watch来回调相应处理逻辑;
watch特性
一次性: watch是一次性的，一旦被触发就会移除，再次使用时需要重新注册。
客户端顺序回调: watcher回调是顺序串行化执行的，只有回调后客户端才能看到最新的数据状态。值得注意的是，一个watch回调逻辑不应该太多，以免影响别的watch执行。
轻量级: WatchEvent是最小的通信单元，结构上只包含通知状态，事件类型和节点路径，并不会告诉数据节点变化前后的具体内容。
时效性: watcher只有在当前session彻底失效时才会无效，若在session有效期内快速重连成功，则watch依然存在，仍可接收到通知。
watch原理
监听原理详解:
- 首先要有一个main()线程;
- 在main线程中创建zookeeper客户端，这时就会创建两个线程，一个是负责网络连接通信(connet)，一个是负责监听(listener);
- 通过connect线程将注册的监听事件发送给zookeeper;
- 在zookeeper的注册监听器列表中将注册的监听事件添加到列表中;
- zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程;
- listener线程内部调用了process()方法;
常见的监听命令:
监听节点数据的变化: get -w path
监听子节点增减的变化: ls -w path
zookeeper应用场景
zookeeper是一个分布式数据一致性解决方案，致力于为分布式应用提供一个高性能，高可用，且具有严格顺序访问控制能力的分布式协调存储服务。
zookeeper包括但不限于以下几点的应用场景:
- 维护配置信息;
- 分布式锁服务;
- 集群管理;
- 生成分布式唯一ID;
- 配置中心;
zookeeper适用于存储和协同相关的关键数据，不适合用于存储大数据量存储
浙公网安备 33010602011771号