Zookeeper基本特性与节点数据


Zookeeper正是一个分布式应用协调框架

什么是zookeeper

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

Zookeeper 核心概念

Zookeeper 是一个用于存储少量数据的基于内存的数据库,主要有如下两个核心的概念:文件系统数据结构+监听通知机制

文件系统数据结构

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

PERSISTENT-持久化目录节点

客户端与zookeeper断开连接后,这种类型节点一旦创建则永远存在,不会被自动删除,除非手动删除

PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与zookeeper断开连接后,这种类型节点一旦创建则永远存在,只是给节点尾部加上序号而已

EPHEMERAL 临时目录节点

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

EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

客户端与zookeeper断开连接后,该节点被删除,只是Zookeeper给该节点名称进行顺序编号

Container 容器节点

Container容器节点3.5.3版本新增的,当这个容器节点下面没有节点的时候,这个容器节点将会被删除,
定时任务默认60s 检查一次

TTL 节点(过了配置的指定时间,被删除,线程轮训不稳定)

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

监听通知机制

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

  1. 如果注册的是对某个节点的监听,则当这个节点被删除,或者被修改时,对应的客户端将被通知
  2. 如果注册的是对某个目录的监听,则当这个目录有子节点被创建,或者有子节点被删除,对应的客户端将被通知
  3. 如果注册的是对某个目录的所有节点,包括递归子节点进行监听,则当这个目录下面的任意子节点有目录结构的变化(有子节点被创建,或被删除)或者根节点有数据变化时,对应的客户端将被通知。这个有点类似于,1和2的结合,支持1的根节点监听 2的批量添加监听

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

Zookeeper 经典的应用场景

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

Zookeeper 实战

安装
先搭建配置java环境
第一篇有关于jdk安装的
因为zookeeper是用java语言编写的
java -version

在这里插入图片描述

下载解压 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

重命名配置文件  zoo_sample.cfg(只是喜欢保留原配置而已)
cd apache-zookeeper-3.5.8-bin/conf
cp zoo_sample.cfg  zoo.cfg 

# 修改配置文件中的数据存放目录
mkdir /usr/local/apache-zookeeper-3.5.8-bin/data
vim zoo.cfg  //将dataDir修改为  /usr/local/apache-zookeeper-3.5.8-bin/data

# 通过zoo.conf启动
bin/zkServer.sh start conf/zoo.cfg

# 检查是否启动成功
ps -ef|grep zookeeper

#通过客户端进行连接bin/zkCli.sh -server ip:port 
//本机访问
bin/zkCli.sh

在这里插入图片描述
连接成功

help

在这里插入图片描述

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

create /test-node testData //创建一个带testData数据的test-node节点
在这里插入图片描述

查看节点
get  /test-node

在这里插入图片描述

修改节点数据
set /test-node test-data-changed

在这里插入图片描述

查看节点状态信息:
stat /test-node 

在这里插入图片描述

cZxid:创建znode的事务ID(Zxid的值)。
ctime:znode创建时间。
mZxid:最后修改znode的事务ID。
mtime:znode最近修改时间。
pZxid:最后添加或删除子节点的事务ID(子节点列表发生变化才会发生改变)。
cversion:znode的子节点结果集版本(一个节点的子节点增加、删除都会影响这个版本)。
dataVersion:znode的当前数据版本(可以做乐观锁)。
aclVersion:表示对此znode的acl版本。
ephemeralOwner:znode是临时znode时,表示znode所有者的 session ID。 如果znode不是临时znode,则该字段设置为零。
dataLength:znode数据字段的长度。
numChildren:znode的子znode的数量。
查看节点状态信息同时查看数据
get -s /test-node
乐观锁

可以通过get -s /test-node获取当前节点的版本号信息
在这里插入图片描述
这个时候如果带上版本号对数据进行修改,如果成功则说明无人修改,失败则修改失败(并发)

set -v 1 /test-node node-test

在这里插入图片描述

创建子节点

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

create /test-node/test-sub-node
查看子节点信息
# ls [-s] [-w] [-R] path
ls /   根节点下面的所有子节点
ls /test-node   查看test-node下节点  加-R递归查所有子节点
创建序号节点
create   /seq-parent  // 创建父目录,单纯为了分类,非必须
create -s /seq-parent/  seq-data  //最后一个斜杠表示在seq-parent节点下面创建一个没有名称的节点,里面存放seq-data数据
0000000000是序号,自增

在这里插入图片描述
也可以再序号节点前面带一个前缀
在这里插入图片描述

创建临时节点
create -e /ephemeral data 
create 后跟一个 -e 创建临时节点 , 临时节点不能创建子节点
创建临时序号节点
create -e -s /ephemeral/data-no data 
create 后跟一个 -e  -s 创建临时序号节点 , 临时序号节点不能创建子节点
创建容器节点
create -c /container
容器节点主要用来容纳字节点,如果没有给其创建子节点,容器节点表现和持久化节点一样,如果给容器节点创建了子节点,后续又把子节点清空,容器节点也会被zookeeper删除。(默认60秒轮询查看)

事件监听机制

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

节点数据监听(针对监听节点数据,包括当前节点的删除,新增不会被监听)
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 的 ACL 权限控制( Access Control List )

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(授权对象)

事务日志

针对每一次客户端的事务操作,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

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

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值