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

一、什么是Zookeeper

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

在这里插入图片描述

二、Zookeeper 核心概念

可以理解为 Zookeeper 是一个用于存储少量数据的基于内存的数据库，主要有如下两个核心的概念：文件系统数据结构+监听通知机制。

1、文件系统数据结构

Zookeeper维护一个类似文件系统的数据结构：
在这里插入图片描述
每个子目录项都被称作为 znode(目录节点)，和文件系统类似，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode。

有四种类型的znode：

  • 1、PERSISTENT-持久化目录节点
    客户端与zookeeper断开连接后，该节点依旧存在，只要不手动删除该节点，他将永远存在
  • 2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
    客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
  • 3、EPHEMERAL-临时目录节点（与一个sessionId绑定，client会一直个server发送ping命令，server会给client回复pong命令。一段时间中如果server端没有收到ping命令，认为连接以断开，删除sessionId.）
    在这里插入图片描述

客户端与zookeeper断开连接后，该节点被删除

  • 4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
    客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
  • 5、 Container 节点（3.5.3 版本新增，如果Container节点下面没有子节点，则Container节点在未来会被Zookeeper自动清除,定时任务默认60s 检查一次）
  • 6、 TTL 节点( 默认禁用，只能通过系统配置 zookeeper.extendedTypesEnabled=true 开启，不稳定)
    在这里插入图片描述

2、监听通知机制

客户端注册监听它关心的任意节点，或者目录节点及递归子目录节点 。

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

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

3、 Zookeeper 经典的应用场景

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

三、Zookeeper 实战

1、zookeeper安装

Step1：配置JAVA环境，检验环境：

java -version

Step2: 下载解压 zookeeper：

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

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

cp zoo_sample.cfg  zoo.cfg

Step4: 启动zookeeper

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

Step5: 检测是否启动成功

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

Step6: 连接服务器

bin/zkCli.sh -server ip:port 

/bin/zkCli.sh -server 192.168.131.171:2181

在这里插入图片描述
已经启动成功了。

2、使用命令行操作zookeeper

输入命令 help 查看zookeeper所支持的所有命令：

[zk: 192.168.131.171:2181(CONNECTED) 0] 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
Command not found: Command not found help
[zk: 192.168.131.171:2181(CONNECTED) 1]

1、 创建zookeeper 节点命令

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

中括号为可选项，没有则默认创建持久化节点
-s: 顺序节点
-e: 临时节点
-c: 容器节点
-t: ttl节点，可以给节点添加过期时间，默认禁用，需要通过系统参数启用

-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”.

如何开启ttl节点：

vim /usr/local/zookeeper/apache-zookeeper-3.5.9-bin/bin/zkServer.sh

然后将配置"-Dzookeeper.extendedTypesEnabled=true"添加到ZOOMAIN中：
在这里插入图片描述

查看目录：

// 查看目录/下内容
ls /

// 遍历查看目录
ls -R /

在这里插入图片描述

创建节点：

create  /test-node some-data

如上，没有加任何可选参数，创建的就是持久化节点。即断开连接重连后，这个节点信息依然存在。

在这里插入图片描述
查询节点：

get  /test-node

在这里插入图片描述
修改节点数据：

set /test-node some-data-changed

在这里插入图片描述
删除节点：

删除某个节点：

delete /节点名称

注意，如果要删除节点和节点下的子节点，可以使用deleteall 命令。

deleteall /节点名称

在这里插入图片描述

delete

查看节点状态信息：

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所有者的 session ID。 如果znode不是临时znode，则该字段设置为零。
dataLength：znode数据字段的长度。
numChildren：znode的子znode的数量。

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

get -s /test-node

在这里插入图片描述

注意，zk中是存在事务的，节点的删除、创建或者数据的修改、session的建立等。但是get不是事务请求！。

  • cZxid：创建节点的事务ID；
  • ctime：节点创建时间；
  • mZxid：修改节点的事务ID，修改节点的value之后，这个值会递增；
  • pZxid：子节点事务ID，有子节点创建和删除的时候这个事务id会变化。注意不是修改子节点的值！
  • cversion: 子节点的版本号，当我们删除或者新建子节点的时候，这个cversion就会递增；
    在这里插入图片描述
  • dataVersion：节点的值版本号，修改值后dataVersion就会递增；
  • aclVersion：权限控制版本号，修改权限后就会递增；
  • ephemeralOwner：如果当前节点是临时节点，则值是绑定的sessionId；不是临时节点，显示0x0;
    在这里插入图片描述
  • dataLength: 节点值的长度；
  • numChildren：拥有的子节点个数；

根据状态数据中的版本号有并发修改数据实现乐观锁的功能：
在这里插入图片描述
/test-node 当前的数据版本是 1 ， 这时客户端 用 set 命令修改数据的时候可以把版本号带上 ：

set -v 1 /test-node changed

如果在执行上面 set命令前， 有人修改了数据，zookeeper 会递增版本号， 这个时候，如果再用以前的版本号去修改，将会导致修改失败，报如下错误
在这里插入图片描述

创建子节点：

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

create /test-node/test-sub-node

在这里插入图片描述
注意：子节点创建之前，父节点必须要已经存在！不能直接创建多个节点！

创建临时节点：

ephemeral ：临时的，短暂的

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

create -e /ephemeral data

在这里插入图片描述
创建序号节点：

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

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

为了容纳子节点，先创建个父目录 /seq-parent:
在这里插入图片描述
在这里插入图片描述
也可以在序号节点前面带一个前缀:
在这里插入图片描述
创建临时顺序节点：

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

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

create -s -e /ephemeral-node data

创建容器节点：

create -c /container

在这里插入图片描述

容器节点主要用来容纳字节点，如果没有给其创建子节点，容器节点表现和持久化节点一样，如果给容器节点创建了子节点，后续又把子节点清空，容器节点也会被zookeeper删除（默认还会存在60s中，60s之后会被清除。zk会有一个60s的轮训。）。

创建容器节点子节点：
在这里插入图片描述
创建ttl节点：

ttl节点就是带有过期时间的节点，使用-t来创建：

// 创建一个名为ttl-node的节点，5秒后过期
create -t 5000 /ttl-node data

在这里插入图片描述
可以看到，5秒后这个节点已经被删除了。注意，这里的过期时间并不一定是准确的，可能过了过期时间后这个节点依然是存在的，只有后台的轮训线程执行到的时候才会去删除节点！

对于一些使用时间较短的节点，可以使用ttl节点，可以省去自己删除的步骤。

2、事件监听机制

节点监听：

针对节点的监听：一旦事件触发，对应的注册立刻被移除，所以事件监听是一次性的。

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

create /watch-test data

get -w /watch-test
stat -w /watch-test

在这里插入图片描述

此时，我们如果修改了这个监听的数据的值，看看会怎么样：
在这里插入图片描述
可以看到，在修改了监听节点的值后，发出了一个事件，告诉我们值被修改了。

注意，就算是其他客户端使用set命令将值设置成和原来的一样（即set成旧的值），还是会触发监听事件。因为每一次修改的不单单只有节点的数据，包括事务ID、版本号等都会改变。

那我们再修改一次呢？
在这里插入图片描述
发现此时并没有再收到监听消息。验证了监听是一次性的！而且，监听事件触发之后，只会告诉我们事件类型和修改路径，并不会返回修改后的值，这样我们就要可以使用"get -w /test-node"命令获取到最新的值并且再一次添加监听事件！

目录监听：

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

ls -w /path

在这里插入图片描述
注意：对目录的监听，只有目录内容发生变化（即新增或删除节点）时才会触发事件。修改节点的数据不会触发监听事件！！！
在这里插入图片描述
可以在删除后使用"ls -w /节点名称"获取最目录结果，并再添加一次监听事件。

针对递归子目录的监听：

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

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

每个子节点都可以触发一次，触发之后就无法再次触发！但是不会其他未触发的子节点事件依然存在。
在这里插入图片描述
删除监听：

removewatches path [-c|-d|-a] [-l]

在这里插入图片描述

3、Zookeeper事件类型：

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

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

与Redis 6中新加的特性一致，弊端是一旦获取到连接后，可以查看到所有的数据。为了防止泄露，必须添加ACL权限控制。

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

Scheme（权限模式）：

用来设置 ZooKeeper 服务器进行权限验证的方式。ZooKeeper 的权限验证方式大体分为两种类型：

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

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

还有一种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将不再进行权限检测。这样性能更好，但是将不具备任何的安全措施。

zookeeper.skipACL=yes

在apache-zookeeper-3.5.9-bin/bin下的zkServer.sh 配置中添加配置信息即可生效。
在这里插入图片描述

生成授权ID的两种方式:

a.代码生成ID:

@Test
public void generateSuperDigest() throws NoSuchAlgorithmException {
    String sId = DigestAuthenticationProvider.generateDigest("gj:test");
    System.out.println(sId);//  gj:X/NSthOB0fD/OT6iilJ55WJVado=
}

b.在xshell 中生成

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

假如现在设置一个用户user1, 密码为pass1.
在这里插入图片描述
这样我们就生成了一个授权ID。

1、auth 加密授权

设置ACL有两种方式

1、节点创建的同时设置ACL

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

// 格式：digest:user_name:授权Id=:授权信息[create、delete、read、wirte、admin等中任意搭配]
// digest表示加密
create /节点名称 节点数据 digest:gj:X/NSthOB0fD/OT6iilJ55WJVado=:cdrwa

// 示例, 给用户user1对节点acl-test-node1只分配了读写权限
create /acl-test-node1 testdata digest:user1:+7K83PhyQ3ijGj0ADmljf0quVwQ=:rw

此时如果没有登录的时候获取数据，会报错：

[zk: 192.168.131.171:2181(CONNECTED) 5] get /acl-test-node1 
org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /acl-test-node1

我们使用用户user1登录后查看，就可以获取到节点信息。

[zk: 192.168.131.171:2181(CONNECTED) 6] addauth digest user1:pass1
[zk: 192.168.131.171:2181(CONNECTED) 7] get /acl-test-node1 
testdata

注意，此时只给用户user1分配了节点的读写权限，如果我们在该节点下创建子节点（需要c权限即create权限，才能创建自及诶单）， 就会报错说没有权限：

[zk: 192.168.131.171:2181(CONNECTED) 8] create /acl-test-node1/sub0 
Authentication is not valid : /acl-test-node1/sub0

在这里插入图片描述

2、或者用setAcl 设置

setAcl /acl-test-node2 digest:user1:+7K83PhyQ3ijGj0ADmljf0quVwQ=:rw

添加授权信息后，不能直接访问，直接访问将报如下异常

[zk: 192.168.131.171:2181(CONNECTED) 4] get /acl-test-node2
org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /acl-test-node2

访问前需要添加授权信息：

[zk: 192.168.131.171:2181(CONNECTED) 5] addauth digest user1:pass1
[zk: 192.168.131.171:2181(CONNECTED) 6] get /acl-test-node2
null

在这里插入图片描述

2、auth 明文授权

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

[zk: 192.168.131.171:2181(CONNECTED) 0] addauth digest user1:pass1
[zk: 192.168.131.171:2181(CONNECTED) 1] create /acl-test-node3 testdata auth:user1:pass1:rw
Created /acl-test-node3
[zk: 192.168.131.171:2181(CONNECTED) 2] getAcl /acl-test-node3
'digest,'user1:x
: rw
[zk: 192.168.131.171:2181(CONNECTED) 3] get /acl-test-node3
testdata

在这里插入图片描述

3、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

4、Super 超级管理员模式

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

DigestAuthenticationProvider中定义

// 用户名不一定要是super，可以自己定义。会对密码使用SHA1加密，然后使用base64编码
-Dzookeeper.DigestAuthenticationProvider.superDigest=super:<base64encoded(SHA1(password))
// 举例：
	// ======= 首先新加一个用户，并生成加密后的密文
[root@localhost bin]# echo -n user2:pass2 | openssl dgst -binary -sha1 | openssl base64
0RphDIvIZHLcNxLVT/hhi2uckEs=

-Dzookeeper.DigestAuthenticationProvider.superDigest=user2:0RphDIvIZHLcNxLVT/hhi2uckEs=

修改bin目录下的zkServer.sh文件：
使用上面生活曾的密文，将用户user2设置成一个super用户：

在这里插入图片描述
验证一下：
在这里插入图片描述
使用user2这个超级管理员登录之后，可以进行任何操作。

五、ZooKeeper 内存数据和持久化

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

内存中的数据：

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存储节点数据的最小单位：

// zk中数据存储结构
public class DataNode implements Record {
    byte data[];  // 存放具体数据
    Long acl; 	// acl信息
    public StatPersisted stat;		// 状态信息
    private Set<String> children = null; // 子节点信息

1、事务日志

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

# dataDir=/tmp/zookeeper
dataDir=/usr/local/zookeeper/apache-zookeeper-3.5.9-bin/data

在这里插入图片描述
version-2是事务持久化的版本号。
在这里插入图片描述
log开头的就是事务日志，是内存中持久化的日志，会顺序继续我们对zk的操作。

zookeeper提供了格式化工具可以进行数据查看事务日志数据 。

org.apache.zookeeper.server.LogFormatter

java -cp slf4j-api-1.7.25.jar:zookeeper-3.5.9.jar:zookeeper-jute-3.5.9.jar org.apache.zookeeper.server.LogFormatter 某一个日志文件

// 示例
java -cp 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/version-2/log.5d

如下是我本地的日志文件格式化效果：
在这里插入图片描述
从左到右分别记录了操作时间，客户端会话ID，CXID，ZXID，操作类型，节点路径，节点数据（用#+ascii 码表示，节点版本。

在集群模式下session会被维护到其他的节点上。

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

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

2、数据快照

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

在这里插入图片描述
这里的log是事务日志。

snapshot就是数据快照，我们可以配置当执行到多少请求的时候触发一次快照。

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

日志查看

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

这里需要一些jar包。

java -cp slf4j-api-1.7.25.jar:zookeeper-3.5.9.jar:zookeeper-jute-3.5.9.jar org.apache.zookeeper.server.SnapshotFormatter snapshot文件的路径

// 示例-cp=-classpath
java -cp slf4j-api-1.7.25.jar:zookeeper-3.5.9.jar:zookeeper-jute-3.5.9.jar org.apache.zookeeper.server.SnapshotFormatter  /usr/local/zookeeper/apache-zookeeper-3.5.9-bin/data/version-2/snapshot.5c

在这里插入图片描述
快照事务日志文件名为： snapshot.<当时最大事务ID>，日志满了即进行下一次事务日志文件的创建

3、有了事务日志，为啥还要快照数据。

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

# zookeeper # 分布式
Logo
华为云开发者联盟

为开发者提供学习成长、分享交流、生态实践、资源工具等服务，帮助开发者快速成长。

更多推荐

cover

【GaussDB(for MySQL)】 Big IN查询优化

avatar 华为云开发者联盟
cover

GaussDB细粒度资源管控技术透视

avatar 华为云开发者联盟
cover

关于Java Chassis 3的契约优先（API First）开发

avatar 华为云开发者联盟