Zookeeper特性与节点数据类型详解

目录

[1. 初识Zookeeper](#1. 初识Zookeeper)

[2. Zookeeper快速开始](#2. Zookeeper快速开始)

[2.1 Zookeeper单机搭建](#2.1 Zookeeper单机搭建)

[2.2 客户端常见命令](#2.2 客户端常见命令)

[2.3 可视化工具](#2.3 可视化工具)

[3. Zookeeper数据结构](#3. Zookeeper数据结构)

[3.1 节点分类](#3.1 节点分类)

[3.2 监听机制](#3.2 监听机制)

[3.3 节点特性](#3.3 节点特性)

[3.4 应用场景](#3.4 应用场景)


1. 初识Zookeeper

ZooKeeper 是一个开源的分布式协调框架 ,是Apache Hadoop 的一个子项目,主要用来解决分布式集群中应用系统的一致性问题 。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。

官方: Apache ZooKeeper

ZooKeeper本质上是一个分布式的小文件存储系统(Zookeeper=文件系统+监听机制) 。提供基于类似于文件系统的目录树方式的数据存储,并且可以对树中的节点进行有效管理,从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化,从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。

Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

2. Zookeeper快速开始

2.1 Zookeeper单机搭建

搭建环境:

  1. 准备一台虚拟机;

  2. 安装jdk(zookeeper的运行环境是jdk8)

jdk安装可参考Linux环境下安装JDK-CSDN博客
第一步: 下载zookeeper

下载地址:Apache ZooKeeper


第二步:.tar.gz文件上传到服务器且解压

上传到服务器

解压:

bash 复制代码
tar -zxvf apache-zookeeper-3.8.3-bin.tar.gz


第三步:修改配置文件

  1. 入conf目录,复制zoo_sample.cfg,修改为zoo.cfg
bash 复制代码
cd /app/zookeeper/apache-zookeeper-3.8.3-bin/conf
cp zoo_sample.cfg zoo.cfg
  1. 修改 zoo.cfg 配置文件,将 dataDir=/tmp/zookeeper 修改为指定的data目录
bash 复制代码
vim zoo.zfg

zoo.cfg中参数含义


第四步: 启动zookeeper server

bash 复制代码
# 可以通过 bin/zkServer.sh 来查看都支持哪些参数 
# 默认加载配置路径conf/zoo.cfg 
bin/zkServer.sh start 
# 启动指定配置文件
bin/zkServer.sh start conf/my_zoo.cfg 45

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


第五步:启动zookeeper client连接Zookeeper server

bash 复制代码
bin/zkCli.sh
# 连接远程的zookeeper server 
bin/zkCli.sh -server ip:port

客户端连接成功,至此,我们就已经完成了一个zookeeper的单机环境搭建。

2.2 客户端常见命令

官方命令文档地址:
https://zookeeper.apache.org/doc/r3.8.0/zookeeperCLI.html
常见命令:

2.3 可视化工具

Zookeeper图形化工具: ZooInspector
https://issues.apache.org/jira/secure/attachment/12436620/ZooInspector.zip
Zookeeper图形化工具:开源的 prettyZoo
Zookeeper图形化工具:收费的 ZooKeeperAssistant

3. Zookeeper数据结构

ZooKeeper 数据模型的结构与 Unix 文件系统很类似,整体上可以看作是一棵树,每个节点称做一个ZNode。

ZooKeeper的数据模型是层次模型,层次模型常见于文件系统。层次模型和key-value模型是两种主流的数据模型。

ZooKeeper使用文件系统模型主要基于以下两点考虑:

  • 文件系统的树形结构便于表达数据之间的层次关系
  • 文件系统的树形结构便于为不同的应用分配独立的命名空间( namespace )

**ZooKeeper的层次模型称作Data Tree,Data Tree的每个节点叫作Znode。**不同于文件系统,每个节点都可以保存数据,每一个 ZNode 默认能够存储 1MB 的数据,每个 ZNode 都可以通过其路径唯一标识,每个节点都有一个版本(version),版本从0开始计数。

3.1 节点分类

zookeeper存在几种不同的节点类型,他们具有不同的生命周期, 一个znode可以使持久性的,也可以是临时性的:

|-------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------|
| 节点类型 | 节点特点/生命周期 | 创建实例 |
| 持久节点(PERSISTENT) | 这样的znode在创建之后即使发生ZooKeeper集群宕机或者client宕机 也不会丢失。 | create /locks |
| 临时节点(EPHEMERAL ) | 当创建该临时节点的客户端会话 因超时或发生异常而关闭时,该 节点也相应在 ZooKeeper 服务 器上被删除。也就是说client宕机或者client在指定的timeout时间内没有给ZooKeeper集群发消息,这样的znode就会消失。 | create -e /locks/DBLock |
| 持久顺序节点(PERSISTENT_SEQUENTIAL) | znode除了具备持久性znode的特点之外,znode的名字具备顺序性。 | create -s /jobs/job |
| 临时顺序节点(EPHEMERAL_SEQUENTIAL) | znode除了具备临时性znode的特点之外,zorde的名字具备顺序性。 | create -e -s /jobs/job (有序临时节点) |
| Container节点 (3.5.3版本新增) | Container容器节点,当容器中没有任何子节点,该容器节点会被zk定期删除(定时任务默认60s 检查一次)。 和持久节点的区别是 ZK 服务端启动后,会有一个单独的线程去扫描,所有的容器节点,当发现容器节点的子节点数量为 0 时,会自动删除该节点。可以用于 leader 或者锁的场景中。 | create -c /work |
| TTL节点 | 带过期时间节点,默认禁用,需要在zoo.cfg中添加 extendedTypesEnabled=true 开 启。 注意:TTL不能用于临时节点 | create -t 3000 /ttl_node |

3.1.1 节点状态信息

接下来,我们创建一个节点,通过stat命令来进行查看一下状态信息;

复制代码
create /myTest01 001
create /myTest01/chilTest
stat /myTest01

**cZxid:**Znode创建的事务id。

**ctime:**节点创建时的时间戳。

**mZxid:**Znode被修改的事务id,即每次对znode的修改都会更新mZxid。

对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id),通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生,zxid对于整个zk都是唯一的,即使操作的是不同的znode。

pZxid: 表示该节点的子节点列表最后一次修改的事务ID,添加子节点或删除子节点就会影响子节点列表,但是修改子节点的数据内容则不影响该ID(注意: 只有子节点列表变更了才会变更pzxid,子节点内容变更不会影响pzxid

**mtime:**节点最新一次更新发生时的时间戳。

cversion:子节点的版本号。当znode的子节点有变化时,cversion 的值就会增加1。

**dataVersion:**数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据),可有效避免了数据更新时出现的先后顺序问题。

**ephemeralOwner:**如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id。如果不是,ephemeralOwner值为0(持久节点)。

在client和server通信之前,首先需要建立连接,该连接称为session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于closed状态, 此时session结束。

dataLength : 数据的长度。

**numChildren :**子节点的数量(只统计直接子节点的数量)。

3.1.2 应用示例

从上述节点状态信息得知,节点本身就有一个(版本号)dataVersion,那么我们利用该信息,是不是就可以实现乐观锁的删除呢?接下来我们用两个客户端演示理解一下。

客户端1: 创建一个节点

复制代码
create /optimisticLock
stat /optimisticLock


客户端2: 删除版本为1的节点

复制代码
delete -v 1 /optimisticLock

删除失败,应为此时数据版本为0


客户端1: 更新节点数据

复制代码
set /optimisticLock update
stat /optimisticLock

更新后版本变为了1


客户端2再次删除版本为1的

复制代码
delete -v 1 /optimisticLock

这次删除成功了。

3.2 监听机制

Zookeeper中的watch机制,必须客户端先去服务端注册监听,这样事件发送才会触发监听,通知给客户端。

监听的对象是事件,支持的事件类型如下:

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

语法:

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

示例:

监听子节点增减变化:

监听节点数据变化示例:

从上述示例中,验证了zk的监听是一次性的。

缺点:

这种一次性的监听会有什么问题呢?说明我们在触发监听后,如果还需要继续监听,则需要手动再次增加监听。那么就会有一些数据监听不到的问题,比如客户端1节点修改后,监听已经触发了,还没有来得及重新增加监听,但是客户端2又修改了节点,然后客户端1才监听增加成功了,那么客户端2修改的数据就没有被监听到。那么有没有在被触发之后,仍然保留,可以继续监听ZNode上的变更的监听呢?Zookeeper 3.6.0版本新增了这样的功能,永久性监听。

漏监听数据的场景图:

3.2.1 永久性Watch

永久性Watch在被触发之后,仍然保留,可以继续监听ZNode上的变更。Zookeeper 3.6.0版本新增了这样的功能

语法: addWatch [-m mode] path

addWatch的作用是针对指定节点添加事件监听,支持两种模式(mode)。

  • PERSISTENT,持久化订阅,针对当前节点的修改和删除事件,以及当前节点对子节点的删除和新增事件。
  • PERSISTENT_RECURSIVE,持久化递归订阅(默认),在PERSISTENT的基础上,增加了子节点修改的事件触发,以及子节点的子节点的数据变化都会触发相关事件(满足递归订阅特性)

PERSISTENT模式示例:

上述示例中验证了PERSISTENT模式的特点:只能监听到当前节点的修改和删除事件,以及当前节点对子节点的删除和新增事件。

PERSISTENT_RECURSIVE模式示例:

没有PERSISTENT模式监听不到子孙节点的问题了。

3.2.2 应用示例理解

接下来,我们利用一个应用场景来体验一下zk节点的监听应用。

比如有一个管理协同服务的管理系统,master得唯一,master可以实时监控woker的情况,master下某个woker挂掉后,重新起一个woker.

解决系统中master唯一:利用节点唯一的特性


监控woker:我们在master下创建一个wokers节点,将3个woker创建在wokers中,监听wokers,当其子节点数量变少,就重新起一个woker。

如下图所示,我们创建这样的节点,stat -w /wokers 监听wokers子节点的变化。

3.3 节点特性总结

同一级节点key名称是唯一的;


创建节点时需要带上全路径
可以自动创建顺序节点


watch 机制,监听节点变化:

事件监听机制类似于观察者模式,watch 流程是客户端向服务端某个节点路径上注册一个 watcher,同时客户端也会存储特定的 watcher,当节点数据或子节点发生变化时,服务端通知客户端,客户端进行回调处理。特别注意:监听事件被单次触发后,事件就失效了
delete 命令只能一层一层删除。提示:新版本可以通过 deleteall 命令递归删除。

delete删除

deleteall 命令递归删除

3.4 应用场景

相关推荐
花嫁代二娃4 小时前
Linux:环境变量
linux
Bug退退退1238 小时前
RabbitMQ 高级特性之事务
java·分布式·spring·rabbitmq
CodeWithMe9 小时前
【Note】《Kafka: The Definitive Guide》第四章:Kafka 消费者全面解析:如何从 Kafka 高效读取消息
分布式·kafka
l1x1n09 小时前
Vim 编辑器常用操作详解(新手快速上手指南)
linux·编辑器·vim
ajassi200011 小时前
开源 python 应用 开发(三)python语法介绍
linux·python·开源·自动化
o不ok!11 小时前
Linux面试问题-软件测试
linux·运维·服务器
DaxiaLeeSuper11 小时前
Prometheus+Grafana+node_exporter监控linux服务器资源的方案
linux·grafana·prometheus
Gauss松鼠会12 小时前
GaussDB应用场景全景解析:从金融核心到物联网的分布式数据库实践
数据库·分布式·物联网·金融·database·gaussdb
尽兴-12 小时前
如何将多个.sql文件合并成一个:Windows和Linux/Mac详细指南
linux·数据库·windows·sql·macos
kfepiza12 小时前
Netplan 中 bridges、bonds、ethernets、vlans 之间的关系 笔记250711
linux·tcp/ip·shell