Hadhoop生态（ZooKeeper）

DashingGuy

已于 2025-04-07 11:28:49 修改

阅读量682

点赞数 9

文章标签： hadoop zookeeper hive

于 2025-03-31 10:11:45 首次发布

本文链接：https://blog.youkuaiyun.com/qq_56799520/article/details/146799370

版权

Hadhoop生态（ZooKeeper）

1、Zookeeper基本知识
2、ZooKeeper 数据模型
- 2.1．数据结构图
- 2.2．节点类型
3． ZooKeeper shell
- 3.1．客户端连接
- 3.2． shell 基本操作
4． ZooKeeper Watcher（监听机制）
5． Zookeeper 典型应用

1、Zookeeper基本知识

1.1． ZooKeeper概述

Zookeeper是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性问题。
ZooKeeper本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
在这里插入图片描述

1.2． ZooKeeper 特性

全局数据一致：集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；
可靠性：如果消息被其中一台服务器接受，那么将被所有的服务器接受。
顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
数据更新原子性：一次数据更新要么成功（半数以上节点成功），要么失
败，不存在中间状态；
实时性：Zookeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

Q ：如何保证全局数据一致性？
客户端所有操作分为：增删改查
其中
事务性操作：增删改
非事务性操作：查

A：
1、针对非事务性操作，因为不涉及数据修改，所以不需要维护一致性
2、针对事务性操作：如果多个客户端同时进行操作，转发给leader，按照事务ID依次执行

在这里插入图片描述

1.3． ZooKeeper 集群角色

在这里插入图片描述
Leader：
Zookeeper 集群工作的核心
事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性；
集群内部各个服务器的调度者。
对于create，setData，delete 等有写操作的请求，则需要统一转发给leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。

Follower：
处理客户端非事务（读操作）请求，转发事务请求给Leader；
参与集群Leader选举投票。
此外，针对访问量比较大的zookeeper集群，还可新增观察者角色。

Observer：
观察者角色，观察Zookeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给Leader服务器进行处理。
不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

ZooKeeper 集群搭建与启动

会重新开一篇文章介绍Hadoop集群的搭建。

在所有虚拟机上启动zk

/export/server/zookeeper/bin/zkServer.sh start

/export/server/zookeeper/bin/zkServer.sh stop #关闭
/export/server/zookeeper/bin/zkServer.sh status #查看状态

通过jps命令查看有没有启动成功
在这里插入图片描述
有Quorum…这个java进程就是启动成功。

2、ZooKeeper 数据模型

ZooKeeper 的数据模型，在结构上和标准文件系统的非常相似，拥有一个层次的命名空间，都是采用树形层次结构ZooKeeper 树中的每个节点被称为—Znode。和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。
但也有不同之处：

Znode 兼具文件和目录两种特点。。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子Znode。用户对Znode 具有增、删、改、查等操作（权限允许的情况下）
Znode 具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。
Znode 存储数据大小有限制。ZooKeeper 虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，当时常规使用中应该远小于此值。
Znode 通过路径引用，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在 ZooKeeper 中，路径由Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

在这里插入图片描述

2.1．数据结构图

在这里插入图片描述

2.2．节点类型

客户端操作zk需要几步
1、连接集群，建立会话
2、根据需求对zk目录树进行增删改查
3、断开连接

Znode 有两种，分别为临时节点和永久节点。
临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。
永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

Znode 还有一个序列化的特性，如果创建的时候指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10位数字，没有数值的数位用0补充，例如“0000000001”)。

在这里插入图片描述

znode的类型：

永久序列化
永久非序列化
临时序列化
临时非序列化

在这里插入图片描述

3． ZooKeeper shell

3.1．客户端连接

[root@node1 bin]# /export/server/zookeeper/bin/zkCli.sh -server node2

如果不加 -server 参数，默认为本机的zk服务localhost
加了-server 参数，则连接指定机器上的zk服务。
输入help,输出 zk shell 提示：

在这里插入图片描述

3.2． shell 基本操作

创建节点：
create [-s] [-e] path data acl
其中，-s或-e分别指定节点特性，顺序或临时节点，若不指定，则表示持久节点；acl用来进行权限控制。
在这里插入图片描述

读取节点：

与读取相关的命令有ls 命令和get 命令，ls命令可以列出Zookeeper指定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点；get命令可以获取Zookeeper指定节点的数据内容和属性信息。
ls path [watch]
get path [watch]
ls2 path [watch]

在这里插入图片描述

更新节点
delete path [version]
若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。
Rmr path
可以递归删除节点。

quota

setquota -n|-b val path 对节点增加限制。
n:表示子节点的最大个数
b:表示数据值的最大长度
val:子节点最大个数或数据值的最大长度
path:节点路径
在这里插入图片描述
listquota path 列出指定节点的quota

子节点个数为2,数据长度-1表示没限制

delquota [-n|-b] path 删除 quota

4． ZooKeeper Watcher（监听机制）

ZooKeeper 提供了分布式数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。
ZooKeeper 中，引入了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。
总的来说可以概括Watcher为以下三个过程：客户端向服务端注册Watcher、服务端事件发生触发Watcher、客户端回调Watcher得到触发事件情况

Watch 机制特点：
1.一次性触发

事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。

2.事件封装

ZooKeeper 使用 WatchedEvent 对象来封装服务端事件并传递。
WatchedEvent 包含了每一个事件的三个基本属性：
通知状态（keeperState），事件类型（EventType）和节点路径（path）

3.event 异步发送

watcher 的通知事件从服务端发送到客户端是异步的。

4.先注册再触发

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

在这里插入图片描述

5． Zookeeper 典型应用

5.1．数据发布/订阅

数据发布/订阅系统即所谓的配置中心，也就是发布者将数据发布到ZooKeeper 的一个节点上，提供订阅者进行数据订阅，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。

ZooKeeper 采用的是推拉相结合的方式：客户端向服务器注册自己需要关注的节点，一旦该节点的数据发生改变，那么服务端就会向相应的客户端发送Watcher 事件通知，客户端接收到消息通知后，需要主动到服务端获取最新的数据。
主要用到了：监听机制。
在这里插入图片描述

5.2．提供集群选举

在分布式环境下，不管是主从架构集群，还是主备架构集群，要求在服务的时候有且有一个正常的对外提供服务，我们称之为master。

当master 出现故障之后，需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。

主要用到了：znode唯一性、临时节点短暂性、监听机制。

在这里插入图片描述

5.3．分布式锁

ZooKeeper 通过数据节点表示一个锁，例如/itcast/lock节点就可以定义一个锁，所有客户端都会调用create()接口，试图在/itcast下创建lock子节点，但是ZooKeeper 的强一致性会保证所有客户端最终只有一个客户创建成功。也就可以认为获得了锁，其它线程Watcher监听子节点变化（等待释放锁，竞争获取资源）。

此外也可以通过znode的序列化特性，给创建znode的客户端自动编号，从而实现所谓的顺序锁的功能。