zookeeper详解

学习了zookeeper的特性与节点的数据类型，这里记录一下学习笔记，有错误，还望指出。

---

前言

在了解Zookeeper之前，需要对分布式相关知识有一定了解，什么是分布式系统呢？通常情况下，单个物理节点很容易达到性能，计算或者容量的瓶颈，所以这个时候就需要多个物理节点来 共同完成某项任务，一个分布式系统的本质是分布在不同网络或计算机上的程序组件，彼此通过信息传递来协同工作的系统，而Zookeeper正是一个分布式应用协调框架，在分布式系统架构中有广泛的应用场景。

---

提示：以下是本篇文章正文内容，下面案例可供参考

一、Zookeeper是什么？

以官方文档的话来解释，ZooKeeper 一个中心化的服务, 用于维护配置信息, 命名服务(naming), 提供分布式同步和集群服务(group services)。

它是一个开源的分布式应用程序协调服务, 作为 Google Chubby 的一个开源实现, 是 Hadoop 和 Hbase 的重要组件。 ZooKeeper 的目标是封装好复杂易出错的关键服务, 暴露简单易用、高效、稳定的接口给用户, 提供 java 和 C 接口。

二、ZooKeeper核心概念

用官方文档解释来说比较高大上，用我们白话文可以理解为Zookeeper是一个用于存储少量数据的基于内存的数据库，
主要有如下两个核心的概念：文件系统数据结构+监听通知机制。

2.1、文件系统数据结构

Zookeeper维护一个类似文件系统的数据结构：

每个子目录项都被称作为 znode(目录节点)，和文件系统类似，我们能够自由的增加、删除 znode，在一个znode下增加、删除子znode。
命名规则：名字是一个用斜杆(/)分隔的路径元素序列, ZK 中每一个节点(znode)都用路径标识。

在3.5.3 版本前有四种类型的znode后续版本新增了两个

1. PERSISTENT­持久化目录节点
   客户端与zookeeper断开连接后，该节点依旧存在，只要不手动删除该节点，他 将永远存在
2. PERSISTENT_SEQUENTIAL­持久化顺序编号目录节点
   客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3. EPHEMERAL­临时目录节点
   客户端与zookeeper断开连接后，该节点被删除
4. EPHEMERAL_SEQUENTIAL­临时顺序编号目录节点
   客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
5. Container 节点（3.5.3 版本新增，如果Container节点下面没有子节点，则Container节点 在未来会被Zookeeper自动清除,定时任务默认60s 检查一次）
6. TTL 节点( 默认禁用，只能通过系统配置 zookeeper.extendedTypesEnabled=true 开启，不稳 定)

2.2、监听通知机制

当一个 znode 改变时会触发一个观察, 且删除 watch。客户端可以通过 watch 来接收到通知, 如果客户端和 ZK 的连接断开了会受到一个本地通知。

这里的Watches是指客户端可以对 znode 设置 watches。对节点的修改会触发 watch, 并清除 watch。一个 watch 触发后 ZK 会发送 通知给客户端。

监听某个节点或者某个目录还是一点小小的区别：

1. 监听某个节点，当这个节点被修该或者删除时，对应的客户端会收到通知
2. 监听某个目录，当这个目前下面创建子节点，或者目录下面的字节点被删除对应的客户端会收到通知
3. 监听某个目录的递归子节点，当这个目录下面的任意子节点有目录结构的变化（例如创建字节点或者删除）或者根节点有数据变化时，对应的客户端将被通知。

注意：所有的通知都是一次性的，及无论是对节点还是对目录进行的监听，递归子节点，监听是对所有子节点的，每个子节点下面的事件同样只会被触发一次。

2.3、Zookeeper 经典的应用场景

1. 分布式配置中心
2. 分布式注册中心
3. 分布式锁
4. 集群选举
5. 分布式屏障
6. 发布/订阅

zookeeper已经被广泛应用于越来越多的大型分布式系统中了，其中包括：Dubbo的注册中心，HDFS的namenode和YARN框架的ResourceManager的HA（用zookeeper解决单点问题实现HA），HBase，Kafka等大数据和分布式系统框架中。

三、Zookeeper实战

zookeeper下载可以直接去官方网站下载最新的版本传送门

也可以直接下载

wget https://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.5.8/apache-zookeeper-3.5.8-bin.tar.gz
tar -zxvf apache-zookeeper-3.5.8-bin.tar.gz
cd  apache-zookeeper-3.5.8-bin

重命名配置文件  zoo_sample.cfg
cp zoo_sample.cfg  zoo.cfg 

启动zookeeper
# 可以通过 bin/zkServer.sh  来查看都支持哪些参数 
bin/zkServer.sh start conf/zoo.cfg

检测是否启动成功
echo stat | nc 192.168.109.200 // 前提是配置文件中中讲 stat 四字命令设置了了白名单 
如：
4lw.commands.whitelist=stat

连接服务器
bin/zkCli.sh -server ip:port 

3.1、使用命令操作Zookeeper

如果不知道zookeeper的命令可以输入help来获取命令：
[zk: localhost:2181(CONNECTED) 80] help
ZooKeeper -server host:port cmd args
	addauth scheme auth
	close 
	config [-c] [-w] [-s]
	connect host:port
	create [-s] [-e] [-c] [-t ttl] path [data] [acl]
	delete [-v version] path
	deleteall path
	delquota [-n|-b] path
	get [-s] [-w] path
	getAcl [-s] path
	history 
	listquota path
	ls [-s] [-w] [-R] path
	ls2 path [watch]
	printwatches on|off
	quit 
	reconfig [-s] [-v version] [[-file path] | [-members serverID=host:port1:port2;port3[,...]*]] | [-add serverId=host:port1:port2;port3[,...]]* [-remove serverId[,...]*]
	redo cmdno
	removewatches path [-c|-d|-a] [-l]
	rmr path
	set [-s] [-v version] path data
	setAcl [-s] [-v version] [-R] path acl
	setquota -n|-b val path
	stat [-w] path
	sync path

1. 创建zookeeper 节点命令及参数

create [-s] [-e] [-c] [-t ttl] path [data] [acl]

中括号为可选项，没有则默认创建持久化节点
-s: 顺序节点
-e: 临时节点
-c: 容器节点
-t:  可以给节点添加过期时间，默认禁用，需要通过系统参数启用
（-Dzookeeper.extendedTypesEnabled=true,  znode.container.checkIntervalMs : (Java system property only) New in 3.5.1: The time interval in milliseconds for each check of candidate container and ttl nodes. Default is "60000".)

创建节点：

create  /test-node some-data

如果不加任何的参数，默认创建的就是持久化节点

查看刚刚创建的节点：

get  /test-node

修改节点数据：

set /test-node some-data-changed

查看节点状态信息：

具体参数意义：
Stat
cZxid：创建znode的事务ID（Zxid的值）。
mZxid：最后修改znode的事务ID。
pZxid：最后添加或删除子节点的事务ID（子节点列表发生变化才会发生改变）。
ctime：znode创建时间。
mtime：znode最近修改时间。
dataVersion：znode的当前数据版本。
cversion：znode的子节点结果集版本（一个节点的子节点增加、删除都会影响这个版本）。
aclVersion：表示对此znode的acl版本。
ephemeralOwner：znode是临时znode时，表示znode所有者的 session ID。 如果znode不是临时znode，则该字段设置为零。
dataLength：znode数据字段的长度。
numChildren：znode的子znode的数量。

创建子节点， 这里要注意，zookeeper是以节点组织数据的，没有相对路径这么一说，所以，所有的节点一定是以 / 开头。

create /test‐node/test‐sub‐node

创建临时节点

create ‐e /ephemeral data

create 后跟一个 -e 创建临时节点 ， 临时节点不能创建子节点

创建序号节点，加参数 -s

create    /seq-parent  data // 创建父目录，单纯为了分类，非必须
create -s /seq-parent/  data // 创建顺序节点。顺序节点将再seq-parent 目录下面，顺序递增

为了容纳子节点，先创建个父目录 /seq-parent

也可以再序号节点前面带一个前缀

创建临时顺序节点,其它增删查改和其他节点无异，不再贴图

create -s -e  /ephemeral-node/前缀-

2. 事件监听机制：
   针对节点的监听：一定事件触发，对应的注册立刻被移除，所以事件监听是一次性的

get  -w  /path   // 注册监听的同时获取数据
stat -w /path   // 对节点进行监听，且获取元数据信息

针对目录的监听，如下图，目录的变化，会触发事件，且一旦触发，对应的监听也会被移除，后续对节点的创建没有触发监听事件

ls -w /path

针对递归子目录的监听

ls -R -w /path ： -R 区分大小写，一定用大写 

如下对/test 节点进行递归监听，但是每个目录下的目录监听也是一次性的，如第一次在/test 目录下创建节点时，触发监听事件，第二次则没有，同样，因为时递归的目录监听，所以在/test/sub0下进行节点创建时，触发事件，但是再次创建/test/sub0/subsub1节点时，没有触发事件。

Zookeeper事件类型：

        None: 连接建立事件
        NodeCreated： 节点创建
        NodeDeleted： 节点删除
        NodeDataChanged：节点数据变化
        NodeChildrenChanged：子节点列表变化
        DataWatchRemoved：节点监听被移除
        ChildWatchRemoved：子节点监听被移除

事务日志

针对每一次客户端的事务操作，Zookeeper都会将他们记录到事务日志中，当然，Zookeeper也会将数据变更应用到内存数据库中。我们可以在zookeeper的主配置文件zoo.cfg 中配置内存中的数据持久化目录，也就是事务日志的存储路径 dataLogDir. 如果没有配置dataLogDir（非必填）, 事务日志将存储到dataDir （必填项）目录，zookeeper提供了格式化工具可以进行数据查看事务日志数据 org.apache.zookeeper.server.LogFormatter

java -classpath .:slf4j-api-1.7.25.jar:zookeeper-3.5.8.jar:zookeeper-jute-3.5.8.jar org.apache.zookeeper.server.LogFormatter /usr/local/zookeeper/apache-zookeeper-3.5.8-bin/data/version-2/log.1

如下是日志文件格式化效果

从左到右分别记录了操作时间，客户端会话ID，CXID,ZXID,操作类型，节点路径，节点数据（用#+ascii 码表示），节点版本。

Zookeeper进行事务日志文件操作的时候会频繁进行磁盘IO操作，事务日志的不断追加写操作会触发底层磁盘IO为文件开辟新的磁盘块，即磁盘Seek。因此，为了提升磁盘IO的效率，Zookeeper在创建事务日志文件的时候就进行文件空间的预分配- 即在创建文件的时候，就向操作系统申请一块大一点的磁盘块。这个预分配的磁盘大小可以通过系统参数 zookeeper.preAllocSize 进行配置。

事务日志文件名为： log.<当时最大事务ID>，应为日志文件时顺序写入的，所以这个最大事务ID也将是整个事务日志文件中，最小的事务ID，日志满了即进行下一次事务日志文件的创建

数据快照

数据快照用于记录Zookeeper服务器上某一时刻的全量数据，并将其写入到指定的磁盘文件中。可以通过配置snapCount配置每间隔事务请求个数，生成快照，数据存储在dataDir 指定的目录中，可以通过如下方式进行查看快照数据（ 为了避免集群中所有机器在同一时间进行快照，实际的快照生成时机为事务数达到 [snapCount/2 + 随机数(随机数范围为1 ~ snapCount/2 )] 个数时开始快照）

java -classpath .:slf4j-api-1.7.25.jar:zookeeper-3.5.8.jar:zookeeper-jute-3.5.8.jar org.apache.zookeeper.server.SnapshotFormatter /usr/local/zookeeper/apache-zookeeper-3.5.8-bin/data-dir/version-2/snapshot.0

快照事务日志文件名为： snapshot.<当时最大事务ID>，日志满了即进行下一次事务日志文件的创建

有了事务日志，为啥还要快照数据。
快照数据主要时为了快速恢复，事务日志文件是每次事务请求都会进行追加的操作，而快照是达到某种设定条件下的内存全量数据。所以通常快照数据是反应当时内存数据的状态。事务日志是更全面的数据，所以恢复数据的时候，可以先恢复快照数据，再通过增量恢复事务日志中的数据即可。

---

一切伟大的行动和思想，都有一个微不足道的开始。