当前位置： 首页 > article >正文

【01】ZooKeeper特性与节点数据类型

article 2024/10/31 17:34:05

1、Zookeeper介绍

  • ZooKeeper是一个开源的分布式协调框架，是Apache Hadoop 的一个子项目，主要用来解决分布式集群中应用系统的一致性问题。Zookeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给客户使用。
  • 官方：https://zookeeper.apache.org/
  • ZooKeeper本质上是一个分布式的小文件存储系统（ZooKeeper = 文件系统 + 监听机制）。提供类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理，从而用来维护和监控存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理、统一命名服务、分布式配置管理、分布式消息队列、分布式锁、分布式协调等功能。
  • ZooKeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，并接受观察者的注册，一旦这些数据的状态发生变化，ZooKeeper 就通知那些已经在ZK上注册的观察者做出相应的反应。

2、Zookeeper快速开始

2.1 安装 ZooKeeper

  • 下载地址：https://zookeeper.apache.org/releases.html

  • 运行环境：jdk8（启动zookeeper需要安装JDK）

  • <1> 将下载好的文件上传某个文件夹下

  • <2> 将这个文件解压至某个文件下：

    tar -zxvf apache-zookeeper-3.6.4-bin.tar.gz -C /xq_home/software/zookeeper

  • <3> 到对应目录下查看，并对文件夹重命名：

    [root@localhost192 software_page]# cd /xq_home/software/zookeeper
[root@localhost192 zookeeper]# ll
drwxr-xr-x. 6 root root 133 10月 27 15:54 apache-zookeeper-3.6.4-bin
[root@localhost192 zookeeper]# mv apache-zookeeper-3.6.4-bin/ zookeeper-3.6.4

  • <4> 修改配置文件：

    • 解压安装包后进入conf目录，复制 zoo_sample.cfg，修改为 zoo.cfg
      cp zoo_sample.cfg  zoo.cfg
    • 操作过程如下：
    • 修改 zoo.cfg 配置文件，将 dataDir=/tmp/zookeeper 修改为指定的data目录
      • zoo.cfg 中参数含义：

  • <5> 启动 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

  • <6> 启动 zookeeper client 连接Zookeeper server

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

2.2 客户端命令行操作

  • 输入命令 help 查看zookeeper支持的所有命令：
  • 常见cli命令：

2.3 GUI工具

  • Zookeeper图形化工具：ZooInspector
  • Zookeeper图形化工具：开源的prettyZoo
  • Zookeeper图形化工具：收费的ZooKeeperAssistant

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

3.1 节点类型

  • ZooKeeper存在以下几种不同的节点类型，它们具有不同的生命周期：

  • 一个ZNode可以是永久的也可以是临时的：

    • 1、持久节点（PERSISTENT）：这样的znode节点在创建之后，即使ZooKeeper集群宕机或者客户端宕机也不会丢失；
    • 2、临时节点（EPHEMERAL）：客户端宕机或者客户端在指定的timeout时间内没有给ZooKeeper集群发消息，这样的节点就会消失；

  • 如果持久节点和临时节点具备顺序性，就诞生了下面两种ZNode节点：

    • 1、持久顺序节点（PERSISTENT_SEQUENTIAL）：znode除了具备持久性的特点之外，znode的名字具备顺序性。
    • 2、临时顺序节点（EPHEMERAL_SEQUENTIAL）：znode除了具备临时性的特点之外，zorde的名字具备顺序性。

  • 容器节点（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

  • 示例：实现分布式锁：

    • 分布式锁要求，如果锁的持有者宕了，锁可以被释放。ZooKeeper 的 临时节点 恰好具备这样的特性。
    • 终端1：
      # 建立客户端连接
zkCli.sh
# 创建临时节点 lock
create –e /lock
# 断开客户端连接
quit
    • 终端2：
      # 建立客户端连接
zkCli.sh
# 创建临时节点，在终端1未退出之前，终端2是无法创建该节点的
create –e /lock
# 监视该节点，当该节点不存在时，则创建
stat –w /lock
create –e /lock

  • 节点状态信息：

    • 类似于树状结构，节点下面可以存储一些信息和属性的。可以通过stat 命令来进行查看。
    • 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(持久节点)。
    • dataLength ： 数据的长度；
    • numChildren ：子节点的数量（只统计直接子节点的数量）；

  • 示例：zookeeper乐观锁删除

3.2 监听机制

  • watch机制，顾名思义是一个监听机制。ZooKeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听通知给客户端。

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

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

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

  • 相关特性：

  • 永久性Watch

    • 在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的功能
      addWatch [-m mode] path
    • addWatch的作用是针对指定节点添加事件监听，支持两种模式：
      • PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
      • PERSISTENT_RECURSIVE，持久化递归订阅(默认)，在PERSISTENT的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）

  • 示例：协同服务

    • 设计一个master-worker的组成员管理系统，要求系统中只能有一个master , master能实时获取系统中worker的情况。保证组里面只有一个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-slave选举也可以用这种方式：
      • 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把/c更新到版本1，实现/c的自增1。
      • 客户端2把/c更新到版本2，实现/c的自增1。
      • 客户端1不知道/c已经被客户端⒉更新过了，还用过时的版本1是去更新/c，更新失败。如果客户端1使用的是无条件更新，/c就会更新为2，没有实现自增1。
    • 使用条件更新可以避免出现客户端基于过期的数据进行数据更新的操作。

3.3 节点特性总结

  • 1、同一级节点 key 名称是唯一的（已存在/lock节点，再次创建会提示已经存在）；
  • 2、创建节点时，需要带上全路径；
  • 3、session 关闭，临时节点清除；
  • 4、自动创建顺序节点；
  • watch 机制，监听节点变化；
    • 事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。
  • delete 命令只能一层一层删除。提示：新版本可以通过 deleteall 命令递归删除。

3.4 应用场景

  • ZooKeeper适用于存储和协同相关的关键数据，不适合用于大数据量存储。
    • 有了上述众多节点特性，使得 zookeeper 能开发不出不同的经典应用场景：
      • 注册中心
      • 数据发布/订阅（常用于实现配置中心）
      • 负载均衡
      • 命名服务
      • 分布式协调/通知
      • 集群管理
      • Master选举
      • 分布式锁
      • 分布式队列
  • 统一命名服务：
    • 在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。
    • 例如：IP不容易记住，而域名容易记住。
    • 利用 ZooKeeper 顺序节点的特性，制作分布式的序列号生成器，或者叫 id 生成器。（分布式环境下使用作为数据库 id，另外一种是 UUID（缺点：没有规律）），ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号。
      /
└── /order
    ├── /order-date1-000000000000001
    ├── /order-date2-000000000000002
    ├── /order-date3-000000000000003
    ├── /order-date4-000000000000004
    └── /order-date5-000000000000005
  • 数据发布/订阅：
    • 数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。
    • 配置信息一般有以下几个特点：
      • 数据量小的KV；
      • 数据内容在运行时会发生动态变化；
      • 集群机器共享，配置一致；
    • ZooKeeper 采用的是推拉结合的方式：
      • 推：服务端会推给注册了监控节点的客户端 Watcher 事件通知；
      • 拉：客户端获取通知后，然后主动到服务端拉去最新的数据；
  • 统一集群管理：
    • 分布式环境中，实时掌握每个节点的状态是必要的，可以根据节点实时状态做出一些调整。
    • ZooKeeper可以实现实时监控节点状态变化：
      • 可将节点信息写入ZooKeeper上的一个ZNode;
      • 监听这个ZNode可以获取它的实时状态变化；
  • 负载均衡：
    • 在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求
  • Master-Worker架构：
    • master-worker是一个广泛使用的分布式架构。 master-work架构中有一个master负责监控worker的状态，并为worker分配任务。
    • 在任何时刻，系统中最多只能有一个master，不可以出现两个master的情况，多个master共存会导致脑裂。
    • 系统中除了处于active状态的master还有一个backup master，如果active master失败了，backup master可以很快的进入active状态。
    • master实时监控worker的状态，能够及时收到worker成员变化的通知。master在收到worker成员变化的时候，通常重新进行任务的重新分配。

3.5 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）。
  • 测试：
    • 取消节点的读权限后，读取/name节点没有权限
    • 取消节点删除子节点的权限
  • auth 授权模式
    • 创建用户
      addauth digest fox:123456
    • 设置权限
      setAcl /name auth:fox:123456:cdrwa

# 加密
echo -n fox:123456 | openssl dgst -binary -sha1 | openssl base64
setAcl /name auth:fox:ZsWwgmtnTnx1usRF1voHFJAYGQU=:cdrwa
    • 退出客户端，重新连接之后获取/name会没权限，需要添加授权用户。
  • digest 授权模式
    • 设置权限：setAcl /tuling/fox digest:fox:ZsWwgmtnTnx1usRF1voHFJAYGQU=:cdrwa
  • IP授权模式
    • 多个指定IP可以通过逗号分隔， 如 setAcl /node-ip ip:IP1:rw,ip:IP2:a
      setAcl /node-ip ip:192.168.109.128:cdwra
create /node-ip  data  ip:192.168.109.128:cdwra
  • Super 超级管理员模式
    • 这是一种特殊的Digest模式， 在Super模式下超级管理员用户可以对Zookeeper上的节点进行任何的操作。需要在启动脚本上通过添加JVM 参数开启：
      # DigestAuthenticationProvider中定义
-Dzookeeper.DigestAuthenticationProvider.superDigest=admin:<base64encoded(SHA1(123456))

4、Zookeeper集群架构

4.1 集群角色

  • Leader：领导者
    • 事务请求（写操作）的唯一调度者和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。对于create、setData、delete等有写操作的请求，则要统一转发给leader处理，leader需要决定编号、执行操作，这个过程称为事务。
  • Follower：跟随者
    • 处理客户端非事务（读操作）请求（可以直接响应），转发事务请求给Leader；参与集群Leader选举投票。
  • Observer：观察者
    • 对于非事务请求可以独立处理（读操作），对于事务性请求会转发给leader处理。Observer节点接收来自leader的inform信息，更新自己的本地存储，不参与提交和选举投票。通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
    • 配置一个ID为3的观察者节点：server.3=192.168.0.3:2888:3888:observer
    • Observer应用场景：
      • 提升集群的读性能。因为Observer和不参与提交和选举的投票过程，所以可以通过往集群里面添加observer节点来提高整个集群的读性能。
      • 跨数据中心部署。 比如需要部署一个北京和香港两地都可以使用的zookeeper集群服务，并且要求北京和香港客户的读请求延迟都很低。解决方案就是把香港的节点都设置为observer。

4.2 集群架构

  • leader节点可以处理读写请求，follower只可以处理读请求。follower在接到写请求时会把写请求转发给leader来处理。
  • Zookeeper数据一致性保证：
    • 全局可线性化(Linearizable )写入∶先到达leader的写请求会被先处理，leader决定写请求的执行顺序。
    • 客户端FIFO顺序∶来自给定客户端的请求按照发送顺序执行。

4.3 三节点ZooKeeper集群搭建

  • 环境准备：三台虚拟机（条件有限也可以在一台虚拟机上搭建ZooKeeper伪集群）

    192.168.65.163
192.168.65.184
192.168.65.186

  • <1> 修改zoo.cfg配置，添加server节点配置

    • server.A=B:C:D

      • A 是一个数字，表示这个是第几号服务器； 集群模式下配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面有一个数据 就是 A 的值，Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个server。
      • B 是这个服务器的地址；
      • C 是这个服务器Follower与集群中的Leader服务器交换信息的端口；
      • D 是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。
      # 修改数据存储目录
dataDir=/data/zookeeper

#三台虚拟机 zoo.cfg 文件末尾添加配置
server.1=192.168.65.163:2888:3888
server.2=192.168.65.184:2888:3888
server.3=192.168.65.186:2888:3888

  • <2> 创建 myid 文件，配置服务器编号

    • 在dataDir对应目录下创建 myid 文件，内容为对应ip的zookeeper服务器编号
      cd /data/zookeeper
# 在文件中添加与 server 对应的编号（注意：上下不要有空行，左右不要有空格）
vim myid
    • 注意：添加 myid 文件，一定要在 Linux 里面创建，在 notepad++里面很可能乱码

  • <3> 启动 zookeeper server 集群

    • 启动前需要关闭防火墙(生产环境需要打开对应端口)
      # 分别启动三个节点的zookeeper server
bin/zkServer.sh start
# 查看集群状态
bin/zkServer.sh status
    • 常见问题：
      • 如果服务启动出现下面异常：
      • 原因：zoo.cfg配置错误或者防火墙没关
        #centos7   
# 检查防火墙状态
systemctl status firewalld
#关闭防火墙
systemctl stop firewalld
systemctl disable firewalld

4.4 Zookeeper四字命令使用

  • 用户可以使用Zookeeper四字命令获取 zookeeper 服务的当前状态及相关信息。用户在客户端可以通过 nc（netcat） 向 zookeeper 提交相应的命令。

  • 安装 nc 命令：

    # centos
yum install nc

  • 四字命令格式：

    echo [command] | nc [ip] [port]

  • 开启四字命令：

    • 方法1： 在zoo.cfg 文件里加入配置项让这些指令放行
      #开启四字命令
4lw.commands.whitelist=*
    • 方法2：在zk的启动脚本zkServer.sh中新增放行指令
      #添加JVM环境变量-Dzookeeper.4lw.commands.whitelist=*
ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"

  • stat 命令

    • stat 命令用于查看 zk 的状态信息，实例如下：
      echo stat | nc 192.168.65.186 2181

  • ruok 命令

    • 用于查看当前 zkserver 是否启动，若返回 imok 表示正常。
      echo ruok | nc 192.168.65.186 2181

4.5 Zookeeper选举原理

  • ZooKeeper的Leader选举过程是基于投票和对比规则的，确保集群中选出一个具有最高优先级的服务器作为Leader来处理客户端请求。以服务启动期间选举为例：
  • 投票对比规则如下：
    • 首先比较epoch，选取具有最大epoch的服务器。epoch用于区分不同的选举轮次，每次重新选举时都会增加epoch。
    • 如果epoch相同，则比较zxid（事务ID），选取事务ID最大的服务器。zxid表示最后一次提交的事务ID。
    • 如果zxid也相同，则比较myid（服务器ID），选取服务器ID最大的服务器。
  • zxid的数据结构：
    • 根据这个工具类，可以得出zxid的数据结构的一些信息。
      • zxid是一个64位的整数，由高32位的epoch和低32位的counter组成。
      • epoch表示ZooKeeper服务器的逻辑时期（logical epoch），它是一个相对时间的概念，用于区分不同的Leader选举周期。
      • counter是一个在每个时期（epoch）内递增的计数器，用于标识事务的顺序。
        public class ZxidUtils {

    public static long getEpochFromZxid(long zxid) {
        return zxid >> 32L;
    }
    public static long getCounterFromZxid(long zxid) {
        return zxid & 0xffffffffL;
    }
    public static long makeZxid(long epoch, long counter) {
        return (epoch << 32L) | (counter & 0xffffffffL);
    }
    public static String zxidToString(long zxid) {
        return Long.toHexString(zxid);
    }

}

http://www.kler.cn/a/373274.html

相关文章：

  • [C++ 核心编程]笔记 4.2.6 初始化列表
  • 【简道云 -注册/登录安全分析报告】
  • 代码随想录day15 二叉树（3）
  • ReactNative Fabric渲染器和组件(5)
  • 深度强化学习-学习笔记
  • 【文心智能体 | AI大师工坊】如何使用智能体插件，完成一款旅游类智能体的开发，来体验一下我的智能体『​​​​​​​背包客』
  • 【LLM论文日更】LongReward：利用人工智能反馈改进长上下文大语言模型
  • 【贪心算法】（第十二篇）
  • 鸿蒙生态崛起带来的机遇与挑战
  • React面试常见题目（基础-进阶）
  • 使用Selenium时，如何模拟正常用户行为？
  • Python数据分析NumPy和pandas（十六、文本格式数据的读取与存储：csv、json、xml和html）
  • 使用 BERT 和逻辑回归进行文本分类及示例验证
  • Pycharm，2024最新版Pycharm现在安装环境配置汉化详细教程！
  • 网管平台（三）：如何高效管理无线网络
  • leetcode:面试题 05.07. 配对交换（python3解法）
  • 第二十章 Vue组件通信之父子通信
  • Flutter Color 大调整，需适配迁移，颜色不再是 0-255，而是 0-1.0，支持更大色域
  • Spring5学习记录（一）之IOC容器管理（基于XML方式）
  • vue前端使用pdfjs与pdfdist-mergeofd 实现预览pdf并翻页，同时解决预览pdf显示模糊的问题
  • 【算法与数据结构】二分查找思想
  • 海外媒体发稿：如何打造媒体发稿策略
  • 【SSM详细教程】-13-SpringMVC详解
  • Convolution 卷积
  • QT 实现自定义动态选择指示器
  • git的学习之远程进行操作