【大数据】Zookeeper 客户端的命令行操作

我们已经搭建好了 Zookeeper 集群,接下来就是启动客户端,在里面输入增删改查相关的命令,然后发送给服务端执行,就类似于 Redis 一样。

# 输入 zkCli.sh 即可启动
# 会自动连接本地的 zookeeper 服务端
# 如果想连接其它节点的端,那么需要加上 -server 参数
# 比如 zkCli.sh -server ip:2181
[root@satori ~]# zkCli.sh

回车之后,客户端便可连接至 Leader 节点。

在这里插入图片描述
然后来看看命令都有哪些?

1.显示某个路径下的所有节点:ls

在这里插入图片描述

2.显示某个路径下的所有节点,以及当前节点的详细信息:ls2

但是该参数已经废弃,推荐使用 ls -s

在这里插入图片描述

不但显示根节点下面的所有节点,还显示了当前根节点的详细信息,就是绿色框框内的部分。那么它们都代表啥含义呢,来解释一下。

  • cZxid:创建节点时的事务 ID,每次向 Zookeeper 写入或者修改数据时都会产生一个事务 ID。它是 Zookeeper 中所有修改的次序,如果 zxid1 小于 zxid2,那么 zxid1 对应的修改操作在 zxid2 之前发生。
  • ctime:当前节点的创建时间,时间戳形式,单位毫秒。
  • mZxid:当前节点最后一次更新的事务 ID。
  • mtime:当前节点最后一次更新的时间,时间戳形式,单位毫秒。
  • pZxid:当前节点的子节点最后一次更新的事务 ID。
  • cversion:当前节点的子节点变化了多少次。
  • dataVersion:当前节点的数据变化了多少次。
  • aclVersion:当前节点访问控制列表多少次。
  • ephemeralOwner:如果节点是临时节点,则表示节点拥有的 Session ID,如果不是则为 0 0 0
  • dataLength:节点可以存储数据,所以它表示数据的长度。
  • numChildren:当前节点的子节点数量。

3.创建节点:create

比如 / 下面只有 Zookeeper 这一个节点,我们再创建一个新的。

在这里插入图片描述

因为节点是用来存储数据的,所以创建节点的时候也应该指定相应的值,正如 Redis 在 set 一个 key 的时候也要指定 value 一样。当然不指定也可以,只不过不指定的话相当于值为 null

通过 create 创建的节点默认是持久节点,那么什么是持久节点呢?首先 Zookeeper 的节点是有类型的,可以分为持久节点和临时节点:

  • 持久节点persistent):客户端和服务端断开连接之后,创建的节点不删除,也就意味着节点上的数据会保留。
  • 临时节点ephemeral):客户端和服务端断开连接之后,创建的节点会自动删除,数据不会被保留。

此外节点还可以带编号和不带编号,如果带编号的话,Zookeeper 会自动在节点的末尾加上一串数字。比如上面的 /ow,它默认是不带编号的,如果我们创建的是带编号的,那么节点创建之后就会变成 /ow001

编号会依次递增,因此带编号的节点也叫做 顺序节点

因此组合起来,Zookeeper 的节点类型总共有 4 4 4 种。其中使用 Zookeeper 作为分布式锁,便是基于 临时顺序节点 实现的。多个客户端同时往 Zookeeper 上面创建临时顺序节点,谁的编号最小,那么谁就先创建成功,我们就认为它拿到了分布式锁。

当客户端操作完共享数据需要释放锁的时候,只需要断开连接即可,这样该客户端创建的临时节点就会自动删除。一旦节点删除,那么它的下一个顺序节点就成了编号最小的节点,从而拿到分布式锁,因此这个机制就避免了因客户端挂掉而导致的死锁问题。

顺序节点 非常有用,特别是在分布式系统中,编号可以用于为所有事件进行全局排序,这样客户端通过顺序号就能推断事件的顺序。

使用 create 创建的节点默认是 持久非顺序 节点,那么其它类型的节点怎么创建呢?

4.创建临时节点:create -e

在这里插入图片描述

临时节点创建完毕,如果此时客户端断开连接,临时节点就会被删除。

在这里插入图片描述
我们重启客户端,再次查看,发现临时节点已经被删除了。

5.创建顺序(带编号)节点:create -s

在这里插入图片描述
创建的时候,自动在结尾加上编号。我这里之前创建过几个,现在编号是从 11 11 11 开始,总之顺序节点的编号是递增的,只会增大,不会减小。

所以 -e 表示临时节点,-s 表示顺序节点,那如果创建 临时顺序节点 呢?很简单,两个参数一块指定即可。

在这里插入图片描述

客户端退出之后,这个临时节点就会消失。

在这里插入图片描述
然后再次创建,发现编号从 14 14 14 开始,因为顺序节点的编号只会依次增加。

6.获取节点内容:get

在这里插入图片描述

如果加上 -s 参数,还可以获取节点的详细信息。

在这里插入图片描述
/china 节点存储的值是 beijing/china/henan 节点存储的值是 zhengzhou。所以 Zookeeper 的数据结构就类似一个树,树上的每一个节点都可以存储具体的值,并且节点之间具有父子关系。

7.修改节点内容:set

在这里插入图片描述
create 表示创建一个新的节点,每个节点会存储一个值,get 表示获取节点存储的值,set 表示修改节点存储的值。

需要注意的是,节点不能重复,所以我们不能这么做:

在这里插入图片描述
因为 /china/henan 这个节点已经存在了,我们不能重复 create,所以要修改节点的值的话,应该使用 set

8.监听某个节点的值的变化:get -w

假设现在有两个客户端同时连接至 Zookeeper 集群,客户端 A 执行 get -w /china 就表示监听 /china 这个节点。然后在客户端 B 上面对 /china 这个节点进行 set,那么 A 机器上就会收到提示,提示我们监听的节点被修改了。

satori 节点上执行 get -w /china,然后返回节点的值,看起来和 get /china 没有什么区别。

在这里插入图片描述

koishi 节点上执行 set /china 北京,将节点的值给改掉。

在这里插入图片描述

再来查看 satori 节点,发现有额外输出。

在这里插入图片描述
注意:监听是一次性的,如果再次 set 的话,那么 A 机器就不会再提示了,除非再次 watch。另外除了节点的值被修改之外会提示,当节点被删除时也会提示。

那么这背后的原理是怎么实现的呢?首先监听的时候,客户端会创建两个子线程,一个负责网络通信(connector),另一个负责监听(listener)。通过 connector 将注册的监听事件发送给服务端,服务端将注册的监听事件添加进注册监听器列表中。

当服务端监听到有数据变化,就会将这个消息发送给 listener 线程,然后 listener 线程将消息输出出来。

9.监听某个节点的子节点变化:ls -w

在这里插入图片描述
当新建一个子节点、或者删除一个子节点的时候,就会收到提示,但是修改不会,所以这里监听的变化指的是 子节点数量 的变化。

:这里只监听子节点的变化,子节点的子节点则不在范围之内。至于实现原理,和 get -w 相同,并且执行 ls -w 之后也只会监听一次。

10.删除节点:delete

在这里插入图片描述

注意:delete 只能删除叶子节点,而非叶子节点、比如这里的 /china 就无法删除。

在这里插入图片描述

在 3.5.0 之前删除非叶子节点使用的命令是 rmr,当然现在也可以使用,只不过废弃了。

在这里插入图片描述

11.查看节点状态:stat

在这里插入图片描述
这些字段的含义我们已经介绍过了,还可以通过 ls -s 或者 get -s 获取。

<think>嗯,用户需要一个大数据Zookeeper介绍文档,用于上台分享。首先,我得明确用户的需求是什么。他们可能需要一个结构清晰、内容全面的Markdown文档,适合在演讲中使用。用户可能是技术人员,或者是对大数据组件有一定了解的听众,所以内容既要有技术深度,也要有易懂的解释。 首先,我应该从Zookeeper的基本概念开始,比如它是什么,主要用途是什么。然后,需要涵盖它的核心特性,比如分布式协调、数据模型、监听机制等。接着,架构设计部分,包括集群角色、数据同步机制ZAB协议,以及持久化和临时节点的区别。这些都是Zookeeper的关键点。 接下来,用户可能需要了解Zookeeper大数据生态中的典型应用场景,比如Hadoop、Kafka中的应用。这部分需要具体例子,说明Zookeeper如何在这些系统中发挥作用,比如管理配置、分布式锁、服务注册等。 然后,实际案例部分可以增强说服力,比如在Kafka中管理Broker和Topic信息,或者在Hadoop中实现高可用。这能让听众更好地理解Zookeeper的实际价值。 最后,最佳实践部分应该包括部署建议、监控、权限管理和数据备份,这些是使用Zookeeper时需要注意的实用建议。总结部分要强调Zookeeper的重要性和适用场景。 需要注意使用Markdown语法,结构要清晰,分章节和子标题,适当使用代码块和列表。同时,避免使用复杂术语,保持语言简洁明了,方便演讲时展示。另外,用户可能需要演讲时的提示,比如每部分的重点,所以内容要层次分明,重点突出。可能需要检查是否有遗漏的重要功能或应用场景,确保内容全面准确。</think>```markdown # Apache Zookeeper 核心解析与大数据应用 ## 目录 1. [Zookeeper 核心概念](#1-zookeeper-核心概念) 2. [分布式协调服务特性](#2-分布式协调服务特性) 3. [集群架构设计解析](#3-集群架构设计解析) 4. [大数据生态应用场景](#4-大数据生态应用场景) 5. [典型应用案例剖析](#5-典型应用案例剖析) 6. [最佳实践指南](#6-最佳实践指南) --- ## 1. Zookeeper 核心概念 ```mermaid graph TD A[分布式系统] --> B[协调难题] B --> C{解决方案} C --> D[Zookeeper] D --> E[统一命名服务] D --> F[配置管理] D --> G[集群管理] D --> H[分布式锁] ``` ### 1.1 设计定位 - **分布式协调中间件**:Google Chubby 开源实现 - **数据一致性保证**:基于ZAB协议的强一致性 - **服务注册中心**:支持临时节点特性 ### 1.2 数据模型 ```python # ZNode结构示例 class ZNode: def __init__(self): self.data = bytearray() # 最大1MB self.children = [] # 子节点列表 self.stat = ZNodeStat() # 版本/时间戳等元数据 ``` --- ## 2. 分布式协调服务特性 ### 2.1 核心特性矩阵 | 特性 | 说明 | 应用场景 | |---------------------|-----------------------------|-------------------------| | 顺序一致性 | 全局事务ID保证操作顺序 | 分布式锁实现 | | 原子性 | 集群范围的操作成功/失败判定 | 配置更新 | | 单一系统镜像 | 客户端连接任意节点视图一致 | 服务发现 | | 可靠性 | 事务持久化到磁盘 | 关键配置存储 | | 实时性 | 客户端最终一致性保证 | 集群状态监控 | ### 2.2 Watch机制 ```java // 伪代码示例 watcher = new Watcher() { void process(WatchedEvent event) { if(event.getType() == EventType.NodeDataChanged) { // 处理配置变更 } } }; zk.getData("/config", watcher, null); ``` --- ## 3. 集群架构设计解析 ### 3.1 集群角色划分 ```mermaid graph LR Client -->|读写请求| Leader Leader -->|提案广播| Follower Follower -->|ACK响应| Leader Observer -->|只读请求| Leader ``` ### 3.2 ZAB协议阶段 1. **发现阶段**:选举准Leader 2. **同步阶段**:数据状态同步 3. **广播阶段**:消息事务传播 --- ## 4. 大数据生态应用场景 ### 4.1 典型组件集成 | 系统名称 | 使用场景 | Zookeeper功能 | |------------|----------------------------|---------------------------| | Hadoop | NN高可用切换 | 故障检测与主节点选举 | | Kafka | Broker注册与ISR管理 | 元数据存储与集群协调 | | HBase | RegionServer状态管理 | 心跳监测与元数据维护 | | Storm | Worker节点协调 | 任务分配与故障转移 | --- ## 5. 典型应用案例剖析 ### 5.1 Kafka集群管理 ```bash # Zookeeper存储结构示例 /kafka ├── brokers # 活动Broker列表 │ └── ids # Broker注册信息 ├── config # Topic配置信息 └── consumers # 消费者组信息 ``` ### 5.2 Hadoop HA实现 ```python # 故障切换流程伪代码 def handle_failover(): while True: if not check_active_nn_health(): create_ephemeral_znode("/hadoop-ha/active") promote_standby_nn() time.sleep(heartbeat_interval) ``` --- ## 6. 最佳实践指南 ### 6.1 部署建议 - **集群规模**:3/5节点(避免偶数节点) - **磁盘隔离**:独立SSD存储事务日志 - **JVM配置**:堆内存4-8GB(禁用swap) ### 6.2 监控指标 ```bash # 关键监控项 zk_avg_latency # 请求平均延迟 zk_open_file_descriptor_count # 文件描述符使用 zk_znode_count # 节点总数 zk_watch_count # 监听器数量 ``` --- # Q&A环节 欢迎提出关于Zookeeper原理、应用场景和故障排查的具体问题! ``` ## 演示要点建议 1. 使用树状图讲解ZNode结构时,可配合kafka目录结构实例 2. 演示Watch机制时,通过命令行实时展示配置变更监听 3. 展示Zookeeper可视化工具(如ZooInspector)的监控界面 4. 对比分析Paxos与ZAB协议的异同点 5. 通过实际故障切换案例说明脑裂问题的解决方案
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

G皮T

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值