一、Zookeeper基本知识
1.1概述
ZooKeeper本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储,并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化,从而可以达到基于数据的集群管理。
1.2特性
全局数据一致:集群中每个服务器保存一份相同的数据副本,client无论连接到哪个服务器,展示的数据都是一致的,这是最重要的特征;
可靠性:如果消息被其中一台服务器接受,那么将被所有的服务器接受。
顺序性:包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。
数据更新原子性:一次数据更新要么成功(半数以上节点成功),要么失败,不存在中间状态;
实时性:Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。
1.3集群角色
Leader:
Zookeeper集群工作的核心
事务请求(写操作)的唯一调度和处理者,保证集群事务处理的顺序性;
集群内部各个服务器的调度者。
对于create,setData,delete等有写操作的请求,则需要统一转发给leader处理,leader需要决定编号、执行操作,这个过程称为一个事务。
Follower:
处理客户端非事务(读操作)请求,转发事务请求给Leader;
参与集群Leader选举投票。
此外,针对访问量比较大的zookeeper集群,还可新增观察者角色。
Observer:
观察者角色,观察Zookeeper集群的最新状态变化并将这些状态同步过来,其对于非事务请求可以进行独立处理,对于事务请求,则会转发给Leader服务器进行处理。
不会参与任何形式的投票只提供非事务服务,通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
二、集群搭建
Zookeeper运行需要java环境,所以需要提前安装jdk。对于安装leader+follower模式的集群,大致过程如下:
配置主机名称到IP地址映射配置
修改ZooKeeper配置文件
远程复制分发安装文件
设置myid
启动ZooKeeper集群
2.1下载压缩包
下载地址:http://archive.apache.org/dist/zookeeper/
2.2解压
在node1主机上,解压zookeeper的压缩包到/export/server路径下去,然后准备进行安装
cd /export/software tar -zxvf zookeeper-3.4.6.tar.gz -C /export/server/ |
2.3配置文件修改
在node1主机上,修改配置文件
cd /export/server/zookeeper-3.4.6/conf/ cp zoo_sample.cfg zoo.cfg mkdir -p /export/server/zookeeper-3.4.6/zkdatas/ vim zoo.cfg |
#修改以下内容
#Zookeeper的数据存放目录
dataDir=/export/server/zookeeper-3.4.6/zkdatas
# 保留多少个快照
autopurge.snapRetainCount=3
# 日志多少小时清理一次
autopurge.purgeInterval=1
# 集群中服务器地址
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
2.4添加myid配置
在node1主机的/export/server/zookeeper-3.4.6/zkdatas/这个路径下创建一个文件,文件名为myid ,文件内容为1
echo 1 > /export/server/zookeeper-3.4.6/zkdatas/myid |
2.5安装包分发
在node1主机上,将安装包分发到其他机器
第一台机器上面执行以下两个命令
scp -r /export/server/zookeeper-3.4.6/ node2:/export/server/ scp -r /export/server/zookeeper-3.4.6/ node3:/export/server/ |
第二台机器上修改myid的值为2
echo 2 > /export/server/zookeeper-3.4.6/zkdatas/myid |
第三台机器上修改myid的值为3
echo 3 > /export/server/zookeeper-3.4.6/zkdatas/myid |
2.6 启动zookeeper服务
三台机器分别启动zookeeper服务
这个命令三台机器都要执行
/export/server/zookeeper-3.4.6/bin/zkServer.sh start |
三台主机分别查看启动状态
/export/server/zookeeper-3.4.6/bin/zkServer.sh status |
2.7配置环境变量
1:分别在三台中,修改/etc/proflie,添加以下内容
export ZOOKEEPER_HOME=/export/server/zookeeper-3.4.6
export PATH=:$ZOOKEEPER_HOME/bin:$PATH
2:分别在三台主机中,source /etc/profile
三、数据模型
![](https://img-blog.csdnimg.cn/img_convert/b5ad59e14cbb8491381d042a583a6ee0.png)
图中的每个节点称为一个Znode。 每个Znode由3部分组成:
ZooKeeper的数据模型,在结构上和标准文件系统的非常相似,拥有一个层次的命名空间,都是采用树形层次结构,ZooKeeper树中的每个节点被称为—Znode。和文件系统的目录树一样,ZooKeeper树中的每个节点可以拥有子节点。但也有不同之处:
Znode兼具文件和目录两种特点,既像文件一样维护着数据、元信息、ACL、时间戳等数据结构,又像目录一样可以作为路径标识的一部分,并可以具有子Znode。用户对Znode具有增、删、改、查等操作(权限允许的情况下)。
Znode具有原子性操作,读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据。另外,每一个节点都拥有自己的ACL(访问控制列表),这个列表规定了用户的权限,即限定了特定用户对目标节点可以执行的操作。
Znode存储数据大小有限制,ZooKeeper虽然可以关联一些数据,但并没有被设计为常规的数据库或者大数据存储,相反的是,它用来管理调度数据,比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据,通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M,当时常规使用中应该远小于此值。
Znode通过路径引用,如同Unix中的文件路径。路径必须是绝对的,因此他们必须由斜杠字符来开头。除此以外,他们必须是唯一的,也就是说每一个路径只有一个表示,因此这些路径不能改变。在ZooKeeper中,路径由Unicode字符串组成,并且有一些限制。字符串"/zookeeper"用以保存管理信息,比如关键配额信息。
① stat:此为状态信息, 描述该Znode的版本, 权限等信息
② data:与该Znode关联的数据
③ children:该Znode下的子节点
四、节点类型
Znode有两种,分别为临时节点和永久节点。
节点的类型在创建时即被确定,并且不能改变。
临时节点:该节点的生命周期依赖于创建它们的会话。一旦会话结束,临时节点将被自动删除,当然可以也可以手动删除。临时节点不允许拥有子节点。
永久节点:该节点的生命周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,他们才能被删除。
Znode还有一个序列化的特性,如果创建的时候指定的话,该Znode的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的,这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10位数字,没有数值的数位用0补充,例如“0000000001”)。
![](https://img-blog.csdnimg.cn/img_convert/d4adc9bd959b90f0304762b9e37f8968.png)
这样便会存在四种类型的Znode节点,分别对应:
PERSISTENT:永久节点
EPHEMERAL:临时节点
PERSISTENT_SEQUENTIAL:永久节点、序列化
EPHEMERAL_SEQUENTIAL:临时节点、序列化
五、zookeeper的shell操作
5.1操作命令
命令 | 说明 | 参数 |
create [-s] [-e] path data [acl] | 创建Znode | -s 指定是顺序节点<br>-e 指定是临时节点 |
ls path [watch] | 列出Path下所有子Znode |
|
get path [watch] | 获取Path对应的Znode的数据和属性 |
|
ls2 path [watch] | 查看Path下所有子Znode以及子Znode的属性 |
|
set path data [version] | 更新节点 | version 数据版本 |
delete path [version] | 删除节点, 如果要删除的节点有子Znode则无法删除 | version 数据版本 |
rmr path | 删除节点, 如果有子Znode则递归删除 |
|
setquota -n|-b val path | 修改Znode配额 | -n 设置子节点最大个数<br>-b 设置节点数据最大长度 |
history | 列出历史记录 |
5.2实例
1:创建普通永久节点
create /app1 hello
2: 创建永久顺序节点
create -s /app2 world
3:创建临时节点
create -e /tempnode world
4:创建顺序的临时节点
create -s -e /tempnode2 aaa
5:获取节点数据
get /app1
6:修改节点数据
set /app1 hadoop
7:删除节点
delete /app1 删除的节点不能有子节点
rmr /app1 递归删除
5.3节点属性
![](https://img-blog.csdnimg.cn/img_convert/aafa1a0dee26e28443dceb6826d32af8.png)
dataVersion:数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据),可有效避免了数据更新时出现的先后顺序问题。
cversion :子节点的版本号。当znode的子节点有变化时,cversion 的值就会增加1。
cZxid :Znode创建的事务id。
mZxid :Znode被修改的事务id,即每次对znode的修改都会更新mZxid。
对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id)。通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生,zxid对于整个zk都是唯一的,即使操作的是不同的znode。
ctime:节点创建时的时间戳.
mtime:节点最新一次更新发生时的时间戳.
ephemeralOwner:如果该节点为临时节点, ephemeralOwner值表示与该节点绑定的session id. 如果不是, ephemeralOwner值为0.
在client和server通信之前,首先需要建立连接,该连接称为session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于CLOSED状态, 此时session结束。
5.3监听机制
ZooKeeper中,引入了Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个Watcher监听,当服务端的一些事件触发了这个Watcher,那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。触发事件种类很多,如:节点创建,节点删除,节点改变,子节点改变等。
临时节点:通过watch机制,会话断开后通知临时节点,临时节点自动删除,通知备用主节点再次创建临时节点
![](https://img-blog.csdnimg.cn/img_convert/ca6174c9082faa24cd00da6683052087.png)
永久节点:数据一旦发生改变,及时通知所有Kafka节点重新读取,保持数据一致
![](https://img-blog.csdnimg.cn/img_convert/465d8e08c857c0934eb8774a7456f2f7.png)
分布式锁:lock节点只能有一个节点访问,实现互斥,node1占用后,其他节点无法访问,node1访问结束后可以由其他节点占用
![](https://img-blog.csdnimg.cn/img_convert/b6ed2f4140b3fc4491d58fe056535e3b.png)