目录
1. 初识Zookeeper
2. Zookeeper快速开始
2.1 Zookeeper单机搭建
2.2 客户端常见命令
2.3 可视化工具
3. Zookeeper数据结构
3.1 节点分类
3.2 监听机制
3.3 节点特性
3.4 应用场景
1. 初识Zookeeper
ZooKeeper 是一个开源的分布式协调框架，是Apache Hadoop 的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。 官方：Apache ZooKeeper
ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。 Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
2. Zookeeper快速开始
2.1 Zookeeper单机搭建
搭建环境：
1. 准备一台虚拟机；
2. 安装jdk(zookeeper的运行环境是jdk8)
jdk安装可参考Linux环境下安装JDK-CSDN博客
第一步： 下载zookeeper
下载地址：Apache ZooKeeper
第二步：.tar.gz文件上传到服务器且解压
上传到服务器
解压：
tar -zxvf apache-zookeeper-3.8.3-bin.tar.gz
第三步：修改配置文件
1. 入conf目录，复制zoo_sample.cfg，修改为zoo.cfg
cd /app/zookeeper/apache-zookeeper-3.8.3-bin/conf
cp zoo_sample.cfg zoo.cfg
2. 修改 zoo.cfg 配置文件，将 dataDir=/tmp/zookeeper 修改为指定的data目录
vim zoo.zfg
zoo.cfg中参数含义
第四步： 启动zookeeper server
# 可以通过 bin/zkServer.sh 来查看都支持哪些参数
# 默认加载配置路径conf/zoo.cfg
bin/zkServer.sh start
# 启动指定配置文件
bin/zkServer.sh start conf/my_zoo.cfg 45
# 查看zookeeper状态 6
bin/zkServer.sh status
第五步：启动zookeeper client连接Zookeeper server
bin/zkCli.sh
# 连接远程的zookeeper server
bin/zkCli.sh -server ip:port
客户端连接成功，至此，我们就已经完成了一个zookeeper的单机环境搭建。
2.2 客户端常见命令
官方命令文档地址：
https://zookeeper.apache.org/doc/r3.8.0/zookeeperCLI.html
常见命令：
2.3 可视化工具
Zookeeper图形化工具：
ZooInspector
https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip
Zookeeper图形化工具：开源的
prettyZoo
Zookeeper图形化工具：收费的
ZooKeeperAssistant
3. Zookeeper数据结构
ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。 ZooKeeper的数据模型是层次模型，层次模型常见于文件系统。层次模型和key-value模型是两种主流的数据模型。
ZooKeeper使用文件系统模型主要基于以下两点考虑:
文件系统的树形结构便于表达数据之间的层次关系文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )
ZooKeeper的层次模型称作Data Tree，Data Tree的每个节点叫作Znode。不同于文件系统，每个节点都可以保存数据，每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识，每个节点都有一个版本(version)，版本从0开始计数。
3.1 节点分类
zookeeper存在几种不同的节点类型，他们具有不同的生命周期，
一个znode可以使持久性的，也可以是临时性的:
节点类型节点特点/生命周期创建实例持久节点(PERSISTENT)这样的znode在创建之后即使发生ZooKeeper集群宕机或者client宕机 也不会丢失。
create /locks
临时节点(EPHEMERAL )
当创建该临时节点的客户端会话
因超时或发生异常而关闭时，该
节点也相应在 ZooKeeper 服务
器上被删除。也就是说client宕机或者client在指定的timeout时间内没有给ZooKeeper集群发消息，这样的znode就会消失。
create -e /locks/DBLock
持久顺序节点(PERSISTENT_SEQUENTIAL)znode除了具备持久性znode的特点之外，znode的名字具备顺序性。
create -s /jobs/job
临时顺序节点(EPHEMERAL_SEQUENTIAL)znode除了具备临时性znode的特点之外，zorde的名字具备顺序性。
create -e -s /jobs/job
(有序临时节点)
Container节点 (3.5.3版本新增)Container容器节点，当容器中没有任何子节点，该容器节点会被zk定期删除（定时任务默认60s 检查一次)。 和持久节点的区别是 ZK 服务端启动后，会有一个单独的线程去扫描，所有的容器节点，当发现容器节点的子节点数量为 0 时，会自动删除该节点。可以用于 leader 或者锁的场景中。
create -c /work
TTL节点带过期时间节点，默认禁用，需要在zoo.cfg中添加 extendedTypesEnabled=true 开 启。 注意：TTL不能用于临时节点
create -t 3000 /ttl_node
3.1.1 节点状态信息
接下来，我们创建一个节点，通过stat命令来进行查看一下状态信息；
create /myTest01 001
create /myTest01/chilTest
stat /myTest01
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(持久节点)。
在client和server通信之前,首先需要建立连接,该连接称为session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于closed状态, 此时session结束。
dataLength ： 数据的长度。
numChildren ：子节点的数量（只统计直接子节点的数量）。
3.1.2 应用示例
从上述节点状态信息得知，节点本身就有一个（版本号）dataVersion，那么我们利用该信息，是不是就可以实现乐观锁的删除呢？接下来我们用两个客户端演示理解一下。
客户端1： 创建一个节点
create /optimisticLock
stat /optimisticLock
客户端2： 删除版本为1的节点
delete -v 1 /optimisticLock
删除失败，应为此时数据版本为0
客户端1： 更新节点数据
set /optimisticLock update
stat /optimisticLock
更新后版本变为了1
客户端2再次删除版本为1的
delete -v 1 /optimisticLock
这次删除成功了。
3.2 监听机制
Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。
监听的对象是事件，支持的事件类型如下：
None: 连接建立事件NodeCreated： 节点创建NodeDeleted： 节点删除NodeDataChanged：节点数据变化NodeChildrenChanged：子节点列表变化DataWatchRemoved：节点监听被移除ChildWatchRemoved：子节点监听被移除
语法：
#监听节点数据的变化
get -w path
stat -w path
#监听子节点增减的变化
ls -w path
示例：
监听子节点增减变化：
监听节点数据变化示例：
从上述示例中，验证了zk的监听是一次性的。
缺点：
这种一次性的监听会有什么问题呢？说明我们在触发监听后，如果还需要继续监听，则需要手动再次增加监听。那么就会有一些数据监听不到的问题，比如客户端1节点修改后，监听已经触发了，还没有来得及重新增加监听，但是客户端2又修改了节点，然后客户端1才监听增加成功了，那么客户端2修改的数据就没有被监听到。那么有没有在被触发之后，仍然保留，可以继续监听ZNode上的变更的监听呢？Zookeeper 3.6.0版本新增了这样的功能，永久性监听。
漏监听数据的场景图：
3.2.1 永久性Watch
永久性Watch在被触发之后，仍然保留，可以继续监听ZNode上的变更。Zookeeper 3.6.0版本新增了这样的功能
语法：addWatch [-m mode] path
addWatch的作用是针对指定节点添加事件监听，支持两种模式（mode）。
PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点对子节点的删除和新增事件。PERSISTENT_RECURSIVE，持久化递归订阅(默认)，在PERSISTENT的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）
PERSISTENT模式示例：
上述示例中验证了PERSISTENT模式的特点：只能监听到当前节点的修改和删除事件，以及当前节点对子节点的删除和新增事件。
PERSISTENT_RECURSIVE模式示例：
没有PERSISTENT模式监听不到子孙节点的问题了。
3.2.2 应用示例理解
接下来，我们利用一个应用场景来体验一下zk节点的监听应用。
比如有一个管理协同服务的管理系统，master得唯一，master可以实时监控woker的情况，master下某个woker挂掉后，重新起一个woker.
解决系统中master唯一：利用节点唯一的特性
监控woker：我们在master下创建一个wokers节点，将3个woker创建在wokers中，监听wokers,当其子节点数量变少，就重新起一个woker。
如下图所示，我们创建这样的节点，stat -w /wokers 监听wokers子节点的变化。
3.3 节点特性总结
同一级节点key名称是唯一的；
创建节点时需要带上全路径
可以自动创建顺序节点
watch 机制，监听节点变化： 事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。
delete 命令只能一层一层删除。提示：新版本可以通过 deleteall 命令递归删除。
delete删除
deleteall 命令递归删除
3.4 应用场景
好文推荐
您阅读本篇文章共花了：
发表评论