Zookeeper实战

1、什么是Zookeeper

在Zookeeper官方文档中给出的接释是,它是一个分布式协调框架,是Apache Hadoop的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

Zookeeper

Zookeeper主要由两个核心概念:文件系统数据结构 + 监听通知机制

1.1 文件系统数据结构

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

zookeeper文件系统的数据结构

每个子目录都被称作为znode(目录节点),和文件系统类似,我们能够自由的增加、删除znode,在一个znode下增加、删除子znode。

有四种类型的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自动清除,定时任务默认60秒检查一次

  6. TTL节点(默认禁用,只能通过系统配置zookeeper.extendedTypesEnabled=true开启,不稳定)

zookeeper节点构成

1.2 监听通知机制

客户端监听他关心的任意节点,或者目录节点以及递归子目录节点

  1. 如果注册的是对某个节点的监听,则当这个节点被删除,或者被修改时,对应的客户端将被通知
  2. 如果注册的是对某个目录的监听,则这个目录有子节点被创建,或者有子节点被删除,对应的客户端将被通知
  3. 如果注册的是对某个目录的递归子节点进行监听,则当目录下面任意子节点有目录结构的变化(有子节点被创建,或者被删除)或者根节点有数据变化时,对应的客户端将通知

注意:所有的通知都是一次性的,无论是对节点还是对目录进行的监听,一旦触发,对应的监听即被删除。递归子节点,监听是对所有子节点的,所以每个子节点下面的事件同样只会被触发一次

1.3 Zookeeper经典应用场景

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

2、Zookeeper安装及使用

2.1 zookeeper安装

Step1: 配置Java环境,检查环境

1
java -version

Step2: 下载解压zookeeper

1
2
3
weget https://archive.apache.org/dist/zookeeper/zookeeper-3.5.9/apache-zookeeper-3.5.9-bin.tar.gz
tar -zxvf apache-zookeeper-3.5.9-bin.tar.gz
cd apache-zookeeper-3.5.9-bin

Step3: 重命名配置文件 zoo_sample.cfg

1
cp zoo_sample.cfg zoo.cfg

Step4: 启动zookeeper

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

Step5: 检查是否启动成功

1
ps -ef | grep java

Step6: 连接服务器

1
bin/zkCli.sh

2.2 zookeeper使用

  1. 创建zookeeper节点命令

    1
    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”)

    创建节点:

    1
    create /test-note some-data

    如上,没有加任何可选参数,创建的就是一个持久化节点
    创建节点

    查看节点:

    1
    get /test-node

    查看节点

    查看节点状态信息:

    1
    stat /test-node

    查看节点状态

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

查看节点状态信息同时查看数据

查看节点状态信息

根据状态数据中的版本号有并发修改数据实现客观锁功能

比如:客户端首先获取版本信息,get -s /node-test

节点版本信息

/test-node当前的数据版本是1,这时客户端用set命令修改数据的时候可以把版本号带上

带版本号修改

如果在执行上面set命令前,有人修改了数据,zookeeper回递增版本号,这个时候如果再用以前的版本号修改,将会导致失败,报错如下:

带版本号修改报错

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

1
create /test-node/test-sub-node

创建子节点

查看子节点的信息,比如根节点下面所有的子节点,加一个大写R可以查看递归子节点列表

1
ls /

查看根节点所有子节点

查看/test-node下面所有的子节点

查看节点

创建临时节点

1
create -e /ephemeral data

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

创建临时节点

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

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

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

创建父目录

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

序号节点前加前缀

创建临时顺序节点,其他增删改查和其他节点无异

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

image-20211003194346735

创建容器节点

1
create -c /container

容器节点主要用来容纳子节点,如果没有给其创建子节点,容器节点表现和持久化节点一样,如果给容器创建了子节点,后续有把子节点清空,容器节点也会被zookeeper删除。

  1. 事件监听机制

    针对节点的监听:一旦事件触发,对应的注册立刻被删除,所以事件监听是一次性的

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

    监听节点

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

1
ls -w /path

监听目录

针对递归子目录的监听

1
ls -R -w /path # -R区分大小写,一定要大写

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

递归子目录监听

Zookeeper事件类型:

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

3、Zookeeper的ACL权限控制(Access Control List)

Zookeeper的ACL权限控制,可以控制节点的读写操作,保证数据的安全性,Zookeeper的ACL权限设置分为3部分组成,分别是:**权限模式(Scheme)授权对象(ID)权限信息(Permission)**。最终组成一条例如”scheme:id:permission”格式的ACL请求信息,下面我们具体看一下这三个部分代表什么意思:

Scheme(权限模式): 用来设置Zookeeper服务器进行权限验证的方式。Zookeeper的权限校验方式大体分为两种类型:

一种是范围验证。所谓的范围验证就是说Zookeeper可以针对一个IP或者一段IP地址授予某种权限。比如我们可以让一个IP地址为“IP:192.168.31.104”的机器对服务器上的某个节点具有写入的权限,或者也可以通过“IP:192.168.31.1/24”给一段IP地址的机器赋予权限。

另一种是模式就是口令验证,也可以理解为用户名密码的方式。在Zookeeper中这种验证方式是Digest认证,而Digest这种认证方式首先在客户端传送“username:password”这种形式的权限表示符后,Zookeeper服务端会对密码部分使用SHA-1和BASWE64算法进行加密,以保证安全性。

还有一种Super权限模式,Super可以认为是一个特殊的Digest认证。具有Super权限的客户端可以对Zookeeper上任意数据节点进行任意的操作。

授权对象(ID):

授权就是说我们要把权限赋予谁,而对应于4种不同的权限模式来说,如果我们选择采用IP方式,使用授权对象可以是一个IP或者IP地址段;而如果使用Digest或Super方式,则对应于一个用户名。如果是World模式,是授权系统中的所有用户。

权限信息(Permission):

权限就是指我们可以在数据节点上执行的操作类型,如下所示:在Zookeeper中已经定义好的权限有5种:

数据节点(c:create)创建权限,授予权限的对象可以在数据节点下==创建子节点==

数据节点(w:write)更新权限,授予权限的对象可更新该数据节点

数据节点(r:read)读取权限,授予权限的对象可以读取该节点的内容以及子节点的列表信息

数据节点(d:delete)删除权限,授予权限的对象可以删除该数据节点的==子节点==

数据节点(a:admin)管理者权限,授予权限的对象可以对该数据节点进行ACL权限设置

命令:

getAcl: 获取某个节点的ACL权限信息

setAcl:设置某个节点的ACL权限信息

addauth:输入认证授权信息,相当于注册用户信息,注册时输入明文密码,zk将以密文的形式存储

可以通过系统参数zookeeper.skipACL = yes进行设置,默认时no,可以设置为true,则配置过的ACL将不再进行权限检测

生成授权ID的两种方式:

  • 代码生成ID

    1
    2
    3
    4
    5
    @Test
    public void generateSuperDigest() throws NoSuchAlgorithmException {
    String sId = DigestAuthenticationProvider.generateDigest("lhb:123456");
    System.out.println(sId);// lhb:nJnredAZxZ1dpEZSzZt/xmcFNUM=
    }
  • 通过命令生成

    1
    echo -n <user>:<password> | openssl dgst -binary -sha1 | openssl base64

设置ACL的两种方式:

  • 节点创建的同时设置ACL

    1
    create [-s][-e][-c] path [data][acl]

    create /zk-node datatest digest:lhb:nJnredAZxZ1dpEZSzZt/xmcFNUM=:cdrwa

  • 使用setAcl设置

    1
    setAcl /zk-node digest:lhb:nJnredAZxZ1dpEZSzZt/xmcFNUM=:cdrwa

添加权限信息后,不能直接访问,在访问前需要添加授权信息

1
2
3
addauth digest gj:test
get /zk-node
datatest

另一种授权模式:auth明文授权

使用前需要先addauth digest username:password注册用户信息,后续可以直接用明文授权。例如:

1
2
3
4
addauth digest u100:p100
create /node-1 node1data auth:u100:p100:cdwra # 这时u100用户授权信息会被zk保存,可以认为当前的授权用户为u100
get /node-1
node1data

IP授权模式:

1
2
setAcl /node-ip ip:192.168.31.127:cdwra
create /node-ip data ip:192.168.31.127:cdwra

多个指定IP可以通过都好分隔开来,例如

1
setAcl /node-ip ip:IP1:rw,ip:IP2:a

Super超级管理员模式:

这是一种特殊的Digest模式,在Super模式下超级管理员用户可以对Zookeeper上的节点进行任何的操作。需要在启动是通过JVM参数开启:

1
2
# DigestAuthenticationProvider中定义
-Dzookeeper.DigestAuthenticationProvider.superDigest=super:<base64encoded(SHA1(password))

4、Zookeeper内存数据的持久化

Zookeeper数据的组织形式为一个类似文件系统的数据结构,而这些数据都是存储在内存中的,所以我们可以认为,Zookeeper是一个基于内存的小型数据库

内存中的数据:

1
2
3
4
5
6
7
8
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();

DataNode是Zookeeper存储节点数据的最小单位

1
2
3
4
5
public class DataNode implements Record {
byte data[];
Long acl;
public StatPersisted stat;
private Set<String> children = null;

5、事务日志

针对每一次客户端的事务操作,Zookeeper都会将他们记录到事务日志中,当然,Zookeeper也会将数据变更应用到内存数据库中。我们可以在zookeeper的主配置文件zoo.cfg中配置内存中的数据持久化目录,也就是事务日志的存储路径dataLogDir。如果没有配置dataLogDir(非必填),事务日志将默认存储到dataDir(必填项)目录。

zookeeper提供了格式化工具(org.apache.zookeeper.server.LogFormatter)可以进行查看事务日志数据

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

如下是我本地的日志文件格式化效果

日志文件格式化效果

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

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

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

6、数据快照

数据快照用于记录Zookeeper服务器上某一时刻的全量数据,并将其写入到指定的磁盘文件中。

可以通过配置snapCount来设置每间隔事务请求个数,生成快照,数据存储在dataDir指定的目录中

可以通过一下方式进行查看快照数据(为了避免集群中所有机器在同一时间进行快照,实际的快照生存成时间为事务数达到[snapCount/2 + 随机数(随机数范围为1~snapCount/2)]个数时开始快照)

1
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>,日志满了即进行下一次事务日志文件的创建。

有了事务日志,为什么还是要快照数据呢?

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

  • 版权声明: 本博客所有文章除特别声明外,著作权归作者所有。转载请注明出处!

请我喝杯咖啡吧~

支付宝
微信