Zookeeper介绍

简介：ZooKeeper 是一个开源的分布式协调框架，是Apache Hadoop 的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。

设计目标：将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。

ZooKeeper本质上是一个分布式的小文件存储系统（Zookeeper=文件系统+监听机制）。

功能：基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调。

设计模式：一个基于观察者模式设计的分布式服务管理框架

官方：Apache ZooKeeper

Zookeeper快速开始

Zookeeper安装

下载地址：Apache ZooKeeper

运行环境：jdk8

修改配置文件

解压安装包后进入conf目录，复制zoo_sample.cfg，修改为zoo.cfg

修改 zoo.cfg 配置文件，将 dataDir=/tmp/zookeeper 修改为指定的data目录

zoo.cfg中参数含义：

启动zookeeper server

# 可以通过 bin/zkServer.sh  来查看都支持哪些参数 
# 默认加载配置路径conf/zoo.cfg
bin/zkServer.sh start
bin/zkServer.sh start conf/my_zoo.cfg

# 查看zookeeper状态
bin/zkServer.sh status

启动zookeeper client连接Zookeeper server

bin/zkCli.sh
# 连接远程的zookeeper server
bin/zkCli.sh -server ip:port

客户端命令行操作

输入命令 help 查看所有命令：

命令基本语法	功能描述
help	显示所有操作命令
ls [-s] [-w] [-R] path	使用 ls 命令来查看当前 znode 的子节点 [可监听] -w: 监听子节点变化 -s: 节点状态信息（时间戳、版本号、数据大小等）-R: 表示递归的获取
create [-s] [-e] [-c] [-t ttl] path [data] [acl]	创建节点-s : 创建有序节点。-e : 创建临时节点。-c : 创建一个容器节点。t ttl] : 创建一个TTL节点， -t 时间（单位毫秒）。data：节点的数据，可选，如果不使用时，节点数据就为null。acl：访问控制
get [-s] [-w] path	获取节点数据信息 -s: 节点状态信息（时间戳、版本号、数据大小等） -w: 监听节点变化
set [-s] [-v version] path data	设置节点数据-s:表示节点为顺序节点-v: 指定版本号
getAcl [-s] path	获取节点的访问控制信息-s: 节点状态信息（时间戳、版本号、数据大小等）
setAcl [-s] [-v version] [-R] path acl	设置节点的访问控制列表-s:节点状态信息（时间戳、版本号、数据大小等）-v:指定版本号-R:递归的设置
stat [-w] path	查看节点状态信息
delete [-v version] path	删除某一节点，只能删除无子节点的节点。-v： 表示节点版本号
deleteall path	递归的删除某一节点及其子节点
setquota -n|-b val path	对节点增加限制n:表示子节点的最大个数b:数据值的最大长度，-1表示无限制

GUI工具

• Zookeeper图形化工具：ZooInspector

• Zookeeper图形化工具：开源的prettyZoo（推荐）

• Zookeeper图形化工具：收费的ZooKeeperAssistant

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<String, DataNode> nodes =
        new ConcurrentHashMap<String, DataNode>();
        
        
    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<String> children = null;
}       

节点分类

zookeeper存在几种不同的节点类型，具有不同的生命周期：

类型	生命周期
持久节点 （persistent node)	一直存在，一直存储在ZooKeeper 服务器上，即使创建该节点的客户端与服务端的会话关闭了，该节点依然不会被删除
临时节点 (ephemeral node)	当创建该临时节点的客户端会话因超时或发生异常而关闭时，该节点也相应在 ZooKeeper 服务器上被删除。
有序节点 (sequential node)	并不算是一种单独种类的节点，而是在之前提到的持久节点和临时节点特性的基础上，增加了一个节点有序的性质。在我们创建有序节点的时候会自动使用一个单调递增的数字作为后缀
容器节点 (container node)	当一个容器节点的最后一个子节点被删除后，容器节点也会被删除
TTL节点 (ttl node)	当一个TTL节点在 TTL 内没有被修改并且没有子节点，会被删除。注意：默认此功能不开启，需要修改配置文件extendedTypesEnabled=true

无序节点：

• 持久节点(PERSISTENT): 这样的znode在创建之后即使发生ZooKeeper集群宕机或者client宕机也不会丢失。

• 临时节点(EPHEMERAL ): client宕机或者client在指定的timeout时间内没有给ZooKeeper集群发消息，这样的znode就会消失。

有序节点：

• 持久顺序节点(PERSISTENT_SEQUENTIAL): znode除了具备持久性znode的特点之外，znode的名字具备顺序性。

• 临时顺序节点(EPHEMERAL_SEQUENTIAL): znode除了具备临时性znode的特点之外，zorde的名字具备顺序性。

以上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

实现分布式锁

分布式锁要求如果锁的持有者宕了，锁可以被释放。

终端一：
zkCli.sh
create –e /lock
quit

终端二：
zkCli.sh
create –e /lock
stat –w /lock
create –e /lock

# ZooKeeper 的 ephemeral 节点，退出终端后自动删除

节点状态信息

[zk: localhost:2181(CONNECTED) 5] stat /lock
cZxid = 0x144
ctime = Wed Dec 20 09:06:28 CST 2023
mZxid = 0x144
mtime = Wed Dec 20 09:06:28 CST 2023
pZxid = 0x144
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x10003e7f7df002e
dataLength = 0
numChildren = 0

• cZxid ：Znode创建的事务id。

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

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

对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id），通过zxid，可以确定更新操作的先后顺序。（zxid全局唯一，数值小的先执行）

• 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机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

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

• None: 连接建立事件

• NodeCreated： 节点创建

• NodeDeleted： 节点删除

• NodeDataChanged：节点数据变化

• NodeChildrenChanged：子节点列表变化

• DataWatchRemoved：节点监听被移除

• ChildWatchRemoved：子节点监听被移除

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

特性	说明
一次性触发	watch是一次性的，一旦被触发就会移除，再次使用时需要重新注册
客户端顺序回调	watch回调是顺序串行执行的，只有回调后客户端才能看到最新的数据状态。一个watcher回调逻辑不应该太多，以免影响别的watch执行
轻量级	WatchEvent是最小的通信单位，结构上只包含通知状态、事件类型和节点路径，并不会告诉数据节点变化前后的具体内容
时效性	watcher只有在当前session彻底失效时才会无效，若在session有效期内快速重连成功，则watcher依然存在，仍可接收到通知；

永久性Watch

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

addWatch [-m mode] path

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

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

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

协同服务

保证master节点只能创建一个：

#master1
create -e /master "m1:2223"  

#master2
create -e /master "m2:2223"   # /master已经存在，创建失败
Node already exists: /master
#监听/master节点
stat -w /master
#当master2收到/master节点删除通知后可以再次发起创建节点操作
create -e /master "m2:2223" 

master监控worker状态的设计思路：

#master服务
create /workers
#让master服务监控/workers下的子节点
ls -w /workers

#worker1
create -e /workers/w1 "w1:2224" #创建子节点，master服务会收到子节点变化通知

#master服务
ls -w /workers
#worker2
create -e /workers/w2 "w2:2224"  #创建子节点，master服务会收到子节点变化通知

#master服务
ls -w /workers
#worker2
quit  #worker2退出，master服务会收到子节点变化通知

条件更新

设想用znode /c实现一个counter，使用set命令来实现自增1操作。条件更新场景∶

1、客户端1把/c更新到版本1，实现/c的自增1。

2、客户端2把/c更新到版本2，实现/c的自增1。

3、客户端1不知道/c已经被客户端⒉更新过了，还用过时的版本1是去更新/c，更新失败。

如果客户端1使用的是无条件更新，/c就会更新为2，没有实现自增1。

使用条件更新可以避免出现客户端基于过期的数据进行数据更新的操作。

节点特性总结

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

已存在/lock节点，再次创建会提示已经存在

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

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

4、自动创建顺序节点

5、watch 机制，监听节点变化

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

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

应用场景详解

ZooKeeper适用于存储和协同相关的关键数据，不适合用于大数据量存储。

• 注册中心

• 数据发布/订阅（常用于实现配置中心）

• 负载均衡

• 命名服务

• 分布式协调/通知

• 集群管理

• Master选举

• 分布式锁

• 分布式队列

统一命名服务

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

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

另外，ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号。（固定前缀有顺序的节点）

数据发布/订阅

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

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

1、数据量小的KV

2、数据内容在运行时会发生动态变化

3、集群机器共享，配置一致

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

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

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

统一集群管理

分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。

ZooKeeper可以实现实时监控节点状态变化：

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

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

负载均衡

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

Master-Worker架构

master-work是一个广泛使用的分布式架构。 master-work架构中有一个master负责监控worker的状态，并为 worker分配任务。

• 在任何时刻，系统中最多只能有一个master，不可以出现两个master的情况，多个master共存会导致脑裂。

• 系统中除了处于active状态的master还有一个backup master，如果active master失败了，backup master可以很快的进入active状态。

• master实时监控worker的状态，能够及时收到worker成员变化的通知。master在收到worker成员变化的时候，通常重新进行任务的重新分配。

ACL权限控制

zookeeper 的 ACL（Access Control List，访问控制表）权限在生产环境是特别重要的，ACL 权限可以针对节点设置相关读写等权限，保障数据安全性。

ACL 构成

zookeeper 的 acl 通过 [scheme:id:permissions] 来构成权限列表。

• scheme：授权的模式，代表采用的某种权限机制，包括 world、auth、digest、ip、super 几种。

• id：授权对象，代表允许访问的用户。如果我们选择采用 IP 方式，使用的授权对象可以是一个 IP 地址或 IP 地址段；而如果使用 Digest 或 Super 方式，则对应于一个用户名。如果是 World 模式，是授权系统中所有的用户。

• permissions：授权的权限，权限组合字符串，由 cdrwa 组成，其中每个字母代表支持不同权限， 创建权限 create(c)、删除权限 delete(d)、读权限 read(r)、写权限 write(w)、管理权限admin(a)。

模式	描述
world	授权对象只有一个anyone，代表登录到服务器的所有客户端都能对该节点执行某种权限
ip	对连接的客户端使用IP地址认证方式进行认证
auth	使用以添加认证的用户进行认证
digest	使用 用户:密码方式验证

权限类型	ACL简写	描述
read	r	读取节点及显示子节点列表的权限
write	w	设置节点数据的权限
create	c	创建子节点的权限
delete	d	删除子节点的权限
admin	a	设置该节点ACL权限的权限

授权命令	用法	描述
getAcl	getAcl path	读取节点的ACL
setAcl	setAcl path acl	设置节点的ACL
create	create path data acl	创建节点时设置acl
addAuth	addAuth scheme auth	添加认证用户，类似于登录操作

auth授权模式

#创建用户
addauth digest gao:123456

#设置权限
setAcl /e auth:gao:123456:cdrwa
# 加密
echo -n gao:123456 | openssl dgst -binary -sha1 | openssl base64
setAcl /e auth:gao:J81lXSx08Ha4M0dq6D51xFfgGoA=:cdrwa

#客户端重新连接后，/e没有权限，需要授权
addauth digest gao:123456

digest授权模式

setAcl /e digest:gao:J81lXSx08Ha4M0dq6D51xFfgGoA=:cdrwa

IP授权模式

setAcl /node-ip ip:192.168.109.128:cdwra
create /node-ip  data  ip:192.168.109.128:cdwra
#多个指定IP可以通过逗号分隔， 如 setAcl /node-ip  ip:IP1:rw,ip:IP2:a

Super 超级管理员模式

一种特殊的Digest模式， 在Super模式下超级管理员用户可以对Zookeeper上的节点进行任何的操作。

需要在启动脚本上通过添加JVM 参数开启：

# DigestAuthenticationProvider中定义
-Dzookeeper.DigestAuthenticationProvider.superDigest=admin:<base64encoded(SHA1(123456))

可插拔身份验证接口

ZooKeeper提供了一种权限扩展机制来让用户实现自己的权限控制方式。

要想实现自定义的权限控制机制，需要继承接口AuthenticationProvider，用户通过该接口实现自定义的权限控制。

public interface AuthenticationProvider 
{
    // 返回标识插件的字符串
    String getScheme();
    // 将用户和验证信息关联起来
    KeeperException.Code handleAuthentication(ServerCnxn cnxn, byte authData[]);
    // 验证id格式
    boolean isValid(String id);
    // 将认证信息与ACL进行匹配看是否命中
    boolean matches(String id, String aclExpr);
    // 是否授权
    boolean isAuthenticated();
}