ZooKeeper特性与节点数据类型详解

目录

Zookeeper介绍

Zookeeper快速开始

ZooKeeper数据结构

 ZooKeeper节点分类

 示例：简单实现分布式锁

ZooKeeper节点状态信息

示例：zookeeper乐观锁删除

ZooKeeper监听机制详解

ZooKeeper节点特性总结

应用场景详解

统一命名服务

数据发布/订阅

统一集群管理

负载均衡

---

Zookeeper介绍

       ZooKeeper是一个开源的分布式协调框架，是Apache Hadoop的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

       ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统 一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

        Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

---

Zookeeper快速开始

下载地址：Apache ZooKeeper

运行环境：jdk8

windows系统下直接启动bin目录下zkServer.cmd文件即可。

Zookeeper图形化工具：https://github.com/vran-dev/PrettyZoo/releases

---

ZooKeeper数据结构

       ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。

         

       ZooKeeper的数据模型是层次模型，层次模型常见于文件系统。层次模型和key-value模型是两种主流的数据模型。ZooKeeper使用文件系统模型主要基于以下两点考虑：

1. 文件系统的树形结构便于表达数据之间的层次关系

2. 文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace)

       ZooKeeper的层次模型称作Data Tree，Data Tree的每个节点叫作Znode。不同于文件系统，每个节点都可以保存数据，每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识，每个节点都有一个版本(version)，版本从0开始计数。

 public class DataTree {
     private final ConcurrentHashMap nodes =
new ConcurrentHashMap();
     private final WatchManager dataWatches = new WatchManager();
     private final WatchManager childWatches = new WatchManager();
 }

 public class DataNode implements Record {
     byte data[];
     Long acl;
     public StatPersisted stat;
     private Set children = null;
 } 

---

 ZooKeeper节点分类

持久节点 （persistent node)

        一直存在，一直存储在ZooKeeper服务器上，即使创建该节点的客户端与服务端的会话关闭了，该节点依然不会被删除。示例：create /locks

临时节点 (ephemeral node)

        当创建该临时节点的客户端会话因超时或发生异常而关闭时，该节点也相应在ZooKeeper服务器上被删除。示例：create -e /locks/DBLock

有序节点 (sequential node)

       并不算是一种单独种类的节点， 而是在之前提到的持久节点和临时节点特性的基础上，增加了一个节点有序的性质。在我们创建有序节点的时候会自动使用一个单调递增的数字作为后缀。示例：create -e -s /jobs/job (有序临时节点)

容器节点 (container node)

       当一个容器节点的最后一个子节点被删除后，容器节点也会被删除。示例：create -c /work

TTL节点 (ttl node) 

        当一个TTL节点在TTL内没有被修改并且没有子节点，会被删除。注意：默认此功能不开启， 需要修改配置文件extendedTypesEnabled=true。示例：create -t 3000 /ttl_node

---

一个znode可以是持久性的，也可以是临时性的:

持久节点(PERSISTENT):

        这样的znode在创建之后即使发生ZooKeeper集群宕机或者client宕机 也不会丢失。

临时节点(EPHEMERAL ):

        client宕机或者client在指定的timeout时间内没有给ZooKeeper集群 发消息，这样的znode就会消失。

如果上面两种znode具备顺序性，又有以下两种znode :

持久顺序节点(PERSISTENT_SEQUENTIAL):

       znode除了具备持久性znode的特点之外，znode 的名字具备顺序性。

临时顺序节点(EPHEMERAL_SEQUENTIAL):

       znode除了具备临时性znode的特点之外，zorde 的名字具备顺序性。

zookeeper主要用到的是以上4种节点。

Container节点 (3.5.3版本新增)：

       Container容器节点，当容器中没有任何子节点，该容器节点会被zk定期删除（定时任务默认60s 检查一次)。 和持久节点的区别是ZK服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为0时，会自动删除该节点。可以用于leader或者锁的场景中。

TTL节点:

       带过期时间节点，默认禁用，需要在zoo.cfg中添加 extendedTypesEnabled=true 开启。 注意：TTL不能用于临时节点。

 #创建持久节点
 create /servers xxx
 #创建临时节点
 create -e /servers/host xxx
 #创建临时有序节点
 create -e -s /servers/host xxx
 #创建容器节点
 create -c /container xxx
 # 创建ttl节点
 create -t 10 /ttl

 示例：简单实现分布式锁

       分布式锁要求如果锁的持有者宕了，锁可以被释放。ZooKeeper的ephemeral节点恰好具备这样的特性。

终端1

zkCli.sh
create –e /lock

终端2

zkCli.sh
create –e /lock
stat –w /lock
create –e /lock

        第一个终端先创建一个lock节点，此时第二个终端也创建该节点，这个时候是不能创建成功的，此时第二个节点对lock节点进行监听，当第一个终端关闭后，lock节点被删除时，此时第二个终端就可以创建出lock节点。

---

ZooKeeper节点状态信息

类似于树状结构，节点下面是可以存储一些信息和属性的。可以通过stat命令来进行查看。

    

cZxid ：Znode创建的事务id。

ctime：节点创建时的时间戳。

mZxid ：Znode被修改的事务id，即每次对znode的修改都会更新mZxid。

        对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id），通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。

pZxid: 表示该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID（注意: 只有子节点列表变更了才会变更pzxid，子节点内容变更不会影响pzxid）

mtime：节点最新一次更新发生时的时间戳.

cversion ：子节点的版本号。当znode的子节点有变化时，cversion 的值就会增加1。

dataVersion：数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。

ephemeralOwner:如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id。如果不是, ephemeralOwner值为0(持久节点)。

dataLength ： 数据的长度

numChildren ：子节点的数量（只统计直接子节点的数量）

---

示例：zookeeper乐观锁删除

ZooKeeper监听机制详解

       watch机制，顾名思义是一个监听机制。Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

监听的对象是事件，支持的事件类型如下：

None: 连接建立事件

NodeCreated： 节点创建

NodeDeleted： 节点删除

NodeDataChanged：节点数据变化

NodeChildrenChanged：子节点列表变化

DataWatchRemoved：节点监听被移除

ChildWatchRemoved：子节点监听被移除

#监听节点数据的变化
get -w path 
stat -w path
#监听子节点增减的变化 
ls -w path 

watch是一次性的，一旦被触发就会移除，再次使用时需要重新注册。

永久性Watch 

在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的功能。

addWatch [-m mode] path

addWatch的作用是针对指定节点添加事件监听，mode支持两种模式

PERSISTENT：

       持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。

PERSISTENT_RECURSIVE：

       持久化递归订阅(默认)，在PERSISTENT的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）。

---

ZooKeeper节点特性总结

1. 同一级节点 key 名称是唯一的。

2.创建节点时，必须要带上全路径

3.session 关闭，临时节点清除

4.自动创建顺序节点

5.watch 机制，监听节点变化事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。

6.delete 命令只能一层一层删除。提示：新版本可以通过 deleteall 命令递归删除。

---

应用场景详解

统一命名服务

在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。

例如：IP不容易记住，而域名容易记住。

数据发布/订阅

       数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

配置信息一般有几个特点:

数据量小的KV 、数据内容在运行时会发生动态变化 、集群机器共享，配置一致

ZooKeeper 采用的是推拉结合的方式。

推: 服务端会推给注册了监控节点的客户端 Watcher事件通知。

拉: 客户端获得通知后，然后主动到服务端拉取最新的数据。

统一集群管理

       分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。 ZooKeeper可以实现实时监控节点状态变化：

1. 可将节点信息写入ZooKeeper上的一个ZNode。

2. 监听这个ZNode可获取它的实时状态变化。

负载均衡

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求