Zookeeper-基础
1. 简介
zookeeper是一个开源的分布式协调服务, 提供分布式数据一致性解决方案,分布式应用程序可以实现数据统一配置管理、统一命名服务、分布式锁、集群管理等功能.
ZooKeeper主要服务于分布式系统,使用分布式系统就无法避免对节点管理的问题(需要实时感知节点的状态、对节点进行统一管理等等),而由于这些问题处理起来可能相对麻烦和提高了系统的复杂性,ZooKeeper作为一个能够通用解决这些问题的中间件就应运而生了。
2. 数据模型
2.1 模型结构
ZooKeeper 提供的命名空间很像标准文件系统的命名空间。名称是由斜杠 (/) 分隔的一系列路径元素。ZooKeeper 命名空间中的每个节点都由路径标识。
与典型的为存储而设计的文件系统不同,ZooKeeper 数据保存在内存中,这意味着 ZooKeeper 可以实现高吞吐量和低延迟。
2.2 模型的特点
- 每个子目录如
/app1
都被称作一个znode(节点)。这个znode是被它所在的路径唯一标识。 - znode可以有子节点目录,并且每个znode可以存储数据。
- znode是有版本的,每个znode中存储的数据可以有多个版本,也就是一个访问路径中可以存储多份数据。每次 znode 的数据更改时,版本号都会增加。例如,每当客户端检索数据时,它也会收到数据的版本。
- 每个znode都有一个访问控制列表 (ACL),它限制了谁可以做什么。
- znode可以被监控,包括这个目录中存储的数据的修改,子节点目录变化等,一旦变化可以通知设置监控的客户端。
⚠️注意:当使用zkCli.sh 创建会话时,节点的监听事件只能被触发一次。
2.3 节点分类
2.3.1 Persistent
持久节点:
节点被创建后,就一直存在,除非客户端主动删除这个节点。
2.3.2 Persistent Sequential
持久顺序节点:
有序的持久节点。在zk中,每个父节点会为它的第一级子节点维护一份时序,会记录每个子节点创建的先后顺序。例如:
2.3.3 Ephemeral
临时节点:
和持久节点不同的是,临时节点的生命周期和客户端会话绑定且临时节点下面不能创建子节点。如果客户端会话失效,那么这个节点就会自动被清除掉。
注意:客户端失效临时节点会被清除,但如果是断开链接,临时节点并不会立马被清除。
“立马”:在会话超时持续时间内未从客户端收到任何心跳信号之后,zk服务器将删除该会话的临时节点。但如果正常关闭会话,临时节点会立马被清除。
2.3.4 Ephemeral Sequential
临时顺序节点:
有序的临时节点。创建es节点时,zk会维护一份时序,会记录每个节点的顺序。例如:
3. 安装
3.1 官方
官方地址:https://zookeeper.apache.org/releases.html
3.2 docker
3.2 docker-compose
⚠️注意:执行脚本前,需先将配置文件挂载到宿主机上。
3.3 配置信息
4. 基础命令
不同版本之前的命令会有所差异,本章是基于zk:3.7版本。官方地址
4.1 创建会话
首先执行命令,创建新的会话,进入终端。
4.2 ls
ls [-s] [-w] [-R] path
:ls 命令用于查看某个路径下目录列表。
-s
:查看此znode状态信息。-w
:监听此znode目录变化。-R
:递归查看。
监听znode目录变化:
4.3 create
create [-s] [-e] [-c] [-t ttl] path [data] [acl]
:create 用于创建znode。
-
-s
:创建顺序节点。 -
-e
:创建临时节点。 -
-c
:创建一个容器节点,当容器中的最后一个子节点被删除时,容器也随之消失。 -
-t
:设置节点存活时间(毫秒)。⚠️注意:如果要设置超时时间需在配置文件中激活配置:
zookeeper.extendedTypesEnabled=true
-
data
:设置的数据。 -
acl
:访问控制配置。
4.4 get
get [-s] [-w] path
: 命令用于获取节点数据和状态信息。
-s
:查看此znode状态信息。-w
:监听此znode值变化。
监听znod值变化:
4.5 stat
stat [-w] path
:命令用于查看节点状态信息。
-w
:监听节点状态变化。
4.6 set
set [-s] [-v version] path data
: 命令用于修改节点存储的数据。
-s
:查看设置成功后的状态信息。-v
:指定设置值的版本号,该值只能为该节点的最新版本。可以使用其实现乐观锁。
4.7 delete
delete [-v version] path
:删除指定节点。
⚠️注意:当删除的节点有子节点时,不能使用该命令。需使用deleteall命令删除。
-v
:删除指定版本。与set
同理
4.8 quit
关闭会话。
5. 节点的监听机制
zk的监听机制,可以使客户端可以监听znode节点的变化,znode节点的变化出发相应的事件,然后清除对该节点的检测。
⚠️注意:在这里再强调一次,当使用zkCli.sh 创建会话时,对znode的监听只能触发一次。但在使用java客户端链接时,可以一直触发。
6. quick start
6.1 项目结构
6.2 引入依赖
Curator 是 Netflix 公司开源的一套 zookeeper 客户端框架,解决了很多 Zookeeper 客户端非常底层的细节开发工作,包括连接重连、反复注册 Watcher 和 NodeExistsException 异常等。
curator-recipes:封装了一些高级特性,如:Cache 事件监听、选举、分布式锁、分布式计数器、分布式 Barrier 等。
6.3 application.yaml
6.4 CuratorClientProperties
6.5 CuratorClientConfig
6.6 CuratorClient
6.7 AppController
7. ZAB 协议介绍
ZAB(ZooKeeper Atomic Broadcast 原子广播) 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性,基于该协议,ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。
ZAB 协议两种基本的模式:崩溃恢复和消息广播
ZAB协议包括两种基本的模式,分别是 崩溃恢复和消息广播。当整个服务框架在启动过程中,或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时,ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器,同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后,ZAB协议就会退出恢复模式。其中,所谓的状态同步是指数据同步,用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。
当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步,那么整个服务框架就可以进人消息广播模式了。 当一台同样遵守ZAB协议的服务器启动后加人到集群中时,如果此时集群中已经存在一个Leader服务器在负责进行消息广播,那么新加人的服务器就会自觉地进人数据恢复模式:找到Leader所在的服务器,并与其进行数据同步,然后一起参与到消息广播流程中去。正如上文介绍中所说的,ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理。Leader服务器在接收到客户端的事务请求后,会生成对应的事务提案并发起一轮广播协议;而如果集群中的其他机器接收到客户端的事务请求,那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。
__EOF__

本文链接:https://www.cnblogs.com/ludangxin/p/15212719.html
关于博主:评论和私信会在第一时间回复。或者直接私信我。
版权声明:本博客所有文章除特别声明外,均采用 BY-NC-SA 许可协议。转载请注明出处!
声援博主:如果您觉得文章对您有帮助,可以点击文章右下角【推荐】一下。您的鼓励是博主的最大动力!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· 什么是nginx的强缓存和协商缓存
· 一文读懂知识蒸馏
· Manus爆火,是硬核还是营销?