1.工作机制
从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
2.特点
- Zookeeper:一个领导者(Leader),多个跟随者(Follower)组成的集群
- 集群中只要有
半数以上节点存活,Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器 - 全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个Server,数据都是一致的
- 更新请求顺序执行,来自同一个Client的更新请求按其发送顺序依次执行。
- 数据更新原子性,一次数据更新要么成功,要么失败。
3.数据结构
Zookeeper数据模型的结构与Unix 文件系统很类似,整体可以看作是一棵树,每个节点称作一个ZNode。每一个ZNode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识。

4.应用场景
4.1统一命名服务
- 在分布式环境下,经常需要对应用/服务进行统一命名,便于识别。
- 例如:IP不容易记住,而域名容易记住

- 例如:IP不容易记住,而域名容易记住
4.2统一配置管理
- 分布式环境下,配置文件同步非常常见
- 一般要求一个集群中,所有节点的配置信息是一致的,比如Kafka集群
- 对配置文件修改后,希望能够快速同步到各个节点上
- 配置管理可以交由Zookeeper实现
- 可将配置文件信息写入Zookeeper上的一个Znode
- 各个客户端服务器监听这个Znode
- 一旦Znode中的数据被修改,Zookeeper将通知各个客户端服务器

4.3统一集群管理
- 分布式环境中,实时掌握每个节点的状态是必要的
- 可以根据节点实时状态做出一些调整
- Zookeeper可以实现实时监控节点状态变化
- 可以将节点信息写入Zookeeper上的一个Znode
- 监听这个Znode可获取它的实时状态变化

4.4服务器节点动态上下线

4.5软负载均衡

5.下载
官网首页:https://zookeeper.apache.org/
下载地址:https://zookeeper.apache.org/releases.html
历史版本下载地址:https://archive.apache.org/dist/zookeeper/
6.本地安装
6.1前提准备
-
安装JDK(集群环境搭建时已经安装过,此处不需要再次安装)
-
下载Zookeeper安装包:apache-zookeeper-3.5.7-bin.tar.gz
wget https://archive.apache.org/dist/zookeeper/zookeeper-3.5.7/apache-zookeeper-3.5.7-bin.tar.gz -P /opt/software/ -
解压
tar -zxvf /opt/software/apache-zookeeper-3.5.7-bin.tar.gz -C /opt/moudle -
修改名称
mv /opt/moudle/apache-zookeeper-3.5.7-bin/ /opt/moudle/zookeeper-3.5.7
6.2修改配置文件
-
配置文件重命名
mv /opt/moudle/zookeeper-3.5.7/conf/zoo_sample.cfg /opt/moudle/zookeeper-3.5.7/conf/zoo.cfg -
新建数据存储目录
mkdir /opt/moudle/zookeeper-3.5.7/zkData -
修改配置文件
vim /opt/moudle/zookeeper-3.5.7/conf/zoo.cfg dataDir=/opt/moudle/zookeeper-3.5.7/zkData
6.3配置文件解读
tickTime=2000:通信心跳时间,Zookeeper服务端和客户端心跳时间,单位:毫秒initLimit=10:LF初始通信时限- Leader和Follower初始连接时能容忍的最多心跳数
- 如果 10 * 2000 毫秒还没有建立连接,则认为本次通信失败
syncLimit=5:LF同步通信时限- Leader和Follower之间通信时间如果超过
syncLimit * tickTime,Leader则认为Follower死掉,从服务器列表中删除Follower
- Leader和Follower之间通信时间如果超过
dataDir:保存Zk中的数据clientPort=2181:客户端连接端口
6.4测试
-
启动服务端
/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh start -
查看任务
jps -l ''' 18327 sun.tools.jps.Jps 18234 org.apache.zookeeper.server.quorum.QuorumPeerMain ''' -
启动客户端
/opt/moudle/zookeeper-3.5.7/bin/zkCli.sh -
查看根节点
[zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] -
退出客户端
[zk: localhost:2181(CONNECTED) 1] quit -
查看Zk状态
/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh status -
停止服务端
/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh stop
7.集群安装
7.1集群规划

7.2按照上述步骤在其中一台服务器(first-node)上安装zk
7.3配置服务器编号
- 在创建的
zkData目录下新建一个myid文件vim /opt/moudle/zookeeper-3.5.7/zkData/myid ``. 在文件中添加与server对应的编号(切记多个服务器之间的编号不能相同) - 编号(整数即可)上下左右不要有空格

7.4将安装好的zk分发给其他两个服务器
-
分发安装包
xsync /opt/moudle/zookeeper-3.5.7 -
修改myid文件中的编码(不要有重复)
ssh second-node echo 2 > /opt/moudle/zookeeper-3.5.7/zkData/myid ssh third-node echo 3 > /opt/moudle/zookeeper-3.5.7/zkData/myid
7.5修改配置文件
-
需要在配置文件
zoo.cfg中增加一下内容vim /opt/moudle/zookeeper-3.5.7/conf/zoo.cfg server.1=first-node:2888:3888 server.2=second-node:2888:3888 server.3=third-node:2888:3888
-
配置参数解读

-
修改完配置后重新分发配置文件
xsync /opt/moudle/zookeeper-3.5.7/conf/zoo.cfg
7.6测试启动集群
- 分别在三台服务器上执行以下启动命令
/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh start
- 检查状态
/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh status



8.ZK选举机制
8.1首次选举(假设有5台服务器)
- 服务器1启动,发起一次选举,服务器1投自己一票,此时服务器1票数一票,不够半数以上(3票),选举无法完成,服务器1状态保持为
LOOKING - 服务器2启动,再次发起一次选举,服务器1和2分别投自己一票,并交换选票信息:
此时服务器1发现服务器2的 myid 比自己目前已投票推举的(服务器1)大,更改选票为推举服务器2。此时服务器1票数为0票,服务器2票数为2票,没有半数以上结果,选举无法完成服务器1、2状态保持为LOOKING - 服务器3启动,发起一次选举,此时服务器1、2都会更改选票为服务器3,此次投票结果:服务器1、2为0票,服务器3为3票,此时服务器3的选票数已经超过半数,服务器3当选Leader,服务器1、2状态更改为
FOLLOWING,服务器3状态更改为LEADING - 服务器4启动,发起一次选举,此时服务器1,2,3已经不是
LOOKING状态,不会更改选票信息,交换选票结果:服务器3为3票,服务器4为1票,此时服务器4服从多数,更改选票信息为服务器3,并更改状态为FOLLOWING - 服务器5启动,同服务器4一样,状态更改为
FOLLOWING
8.2非第一次选举
-
当ZooKeeper集群中的一台服务器出现以下两种情况之一时,就会开始进入Leader选举
- 1.服务器初始化启动
- 2.服务器运行期间,无法和Leader保持连接
-
ID
SID:服务器ID,用来标识一台ZooKeeper集群中的机器,每台机器不能重复,和myid一致ZXID:事物ID,用来标识一次服务器状态的变更,在某一时刻,集群中的每台机器的ZXID值不一定完全一致,这和ZooKeeper服务器对于客户端更新请求的处理逻辑有关Epoch:每个Leader任期时的代号,没有Leader时,同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加
-
而当一台机器进入Leader选举流程时,当前集群也可能会处于以下两种状态
- 1.集群中本来就已经存在一个Leader(自己连接失败)
- 机器试图去选举Leader时,会被告知当前服务器Leader的信息,对于该机器来说,仅仅需要去和Leader进行连接
- 2.集群中确实不存在一个Leader
- 假设ZooKeeper由5台服务器组成,
SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID为3的服务器是Leader,某一时刻3和5服务器出现故障,因此进行Leader选举
- 假设ZooKeeper由5台服务器组成,

- 1.集群中本来就已经存在一个Leader(自己连接失败)
9.ZK集群启动停止脚本
-
在用户bin目录下创建
zk.sh文件,内容如下#! /bin/bash case $1 in "start"){ for node in first-node second-node third-node do echo ----------------------zookeeper $node start-------------------- ssh $node "/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh start" done };; "stop"){ for node in first-node second-node third-node do echo ----------------------zookeeper $node stop-------------------- ssh $node "/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh stop" done };; "status"){ for node in first-node second-node third-node do echo ----------------------zookeeper $node status-------------------- ssh $node "/opt/moudle/zookeeper-3.5.7/bin/zkServer.sh status" done };; esac -
修改权限,使其可执行
chmod 777 /home/fatpuffer/bin/zk.sh -
测试,是否能正常使用
zk.sh start zk.sh stop zk.sh status -
使用xsync分发给集群内的其他服务器
xsync /home/fatpuffer/bin/zk.sh
10.ZK客户端命令操做
10.1命令行语法
| 命令基本语法 | 功能描述 | 示例 |
|---|---|---|
| help | 显示所有操做命令 | lelp |
| ls path | 使用 ls 命令来查看当前znode的子节点【可监听】 -w:监听子节点变化 -s:附加次级信息 | ls / ls -s /zookeeper |
| create | 普通创建 -s:含有序列 -e:临时(重启或者超时消失) | create /wangzherongyao |
| get path | 获得节点的值【可监听】 -w:监听节点内容变化 -s:附加次级信息 | get /wangzherongyao |
| set | 设置节点的具体值 | set /wangzherongyao fashi |
| stat | 查看节点状态 | stat /wangzherongyao |
| delete | 删除节点(如果有子节点则无法删除) | delete /wangzherongyao/fashi |
| deleteall | 递归删除节点(会删除当前节点以及子节点) | delete /wangzherongyao/zhanshi |
| quit | 退出客户端 | quit |
10.2启动客户端
-
连接本地服务器启动
/opt/moudle/zookeeper-3.5.7/bin/zkCli.sh
-
指定服务器连接启动
/opt/moudle/zookeeper-3.5.7/bin/zkCli.sh -server second-node:2181
10.3查看当前znode中包含的所有内容
[zk: second-node:2181(CONNECTED) 1] ls /
[zookeeper]
10.4查看当前节点详细数据
[zk: second-node:2181(CONNECTED) 2] ls -s /
[zookeeper]cZxid = 0x0
ctime = Thu Jan 01 08:00:00 CST 1970
mZxid = 0x0
mtime = Thu Jan 01 08:00:00 CST 1970
pZxid = 0x0
cversion = -1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 0
numChildren = 1
cZxid:创建节点的事务 zxid- 每次修改ZK状态都会产生一个ZK事务ID,事务ID是ZK中所有修改总的次序。每次修改都有唯一的
zxid,如果zxid1小于zxid2,那么zxid1在zxid2之前发生
- 每次修改ZK状态都会产生一个ZK事务ID,事务ID是ZK中所有修改总的次序。每次修改都有唯一的
ctime:znode被创建的毫秒数(从1970年开始)mZxid:znode最后更新的事务zxidmtime:znode最后修改的毫秒数(从1970年开始)pZxid:znode最后更新的子节点事务zxidcversion:znode子节点变化号,znode子节点修改次数dataVersion:znode数据变化号aclVersion:znode访问控制列表的变化号ephemeralOwner:如果是临时节点,这个是znode拥有者的session id。如果不是临时节点,则是0dataLength:znode的数据长度numChildren:znode子节点数量
10.5ZK节点类型(持久/短暂/有序号/无序号)
- 持久(Persistent):客户端和服务器端断开连接后,创建的节点不删除
- 持久节点
带序号 - 持久节点
不带序号
- 持久节点
- 短暂(Ephemeral):客户端和服务器端断开连接后,创建的节点自动删除
- 临时节点
带序号 - 临时节点
不带序号
- 临时节点
说明:创建znode时设置顺序标识,znode名称后会附加一个值,顺序号是一个单调递增的计数器,由父节点维护注意:在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序

10.6创建节点
-
在
/节点下创建一个wangzherongyao永久节点(不带序号)create /wangzherongyao -
在
wangzherongyao节点下创建一个fashi永久节点(不带序号),并且初始化数据为:diaochancreate /wangzherongyao/fashi diaochan -
在
wangzherongyao节点下创建一个zhanshi永久节点(带序号),并且初始化数据为:yasecreate -s /wangzherongyao/zhanshi "yase" -
在
wangzherongyao节点下创建一个zhanshi永久节点(带序号),并且初始化数据为:lixincreate -s /wangzherongyao/zhanshi "lixin"- 永久节点不会因为断开连接而自动删除
- 如果不带序号,则本次创建永久节点
zhanshi时就会报错该节点已存在
-
在
wangzherongyao节点下创建一个sheshou临时节点(不带序号),并且初始化数据为:lubancreate -e /wangzherongyao/sheshou "luban" -
在
wangzherongyao节点下创建一个sheshou临时节点(带序号),并且初始化数据为:houyicreate -e -s /wangzherongyao/sheshou "houyi"- 临时节点断开连接后节点会自动被删除
- 如果不带序号再次创建
sheshou节点,会抛异常,提示该节点已存在
10.7查看节点信息
-
查看节点存储的数据
[zk: second-node:2181(CONNECTED) 49] get /wangzherongyao/sheshou luban -
查看节点详情
[zk: second-node:2181(CONNECTED) 51] get -s /wangzherongyao/sheshou luban cZxid = 0x40000000d ctime = Wed Dec 07 22:29:52 CST 2022 mZxid = 0x40000000d mtime = Wed Dec 07 22:29:52 CST 2022 pZxid = 0x40000000d cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x200000c48be0000 dataLength = 5 numChildren = 0
10.8修改节点数据
-
修改节点
wangzherongyao/sheshou的值为:mengyaset /wangzherongyao/sheshou "mengya"
10.9删除节点
-
1.删除单个节点
- 删除的节点下如果有子节点会删除失败
deleteall /wangzherongyao/fashi -
2.递归删除单节点
- 删除的节点下如果有子节点会递归删除
deleteall /wangzherongyao/fuzhu
- 删除的节点下如果有子节点会递归删除
-
3.递归删除多节点
- 删除的节点下如果有子节点会递归删除
deleteall /wangzherongyao/sheshou /wangzherongyao/zhanshi
10.10监听器原理
-
1.定义
- 客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、节点删除、子目录节点增加或删除)时,ZK会通知客户端。监听机制保证ZK保存的任何数据的改变都能快速的响应到监听了该节点的所有应用
-
2.基本原理
- 1.首先要有一个
main()线程 - 2.在main线程中创建ZK客户端,这时就会创建两个线程,一个负责网络连接通信(connect),另一个负责监听(listener)
- 3.通过
connect线程将注册的监听事件发送给ZK - 4.在ZK服务端的注册监听器列表中将注册的事件添加到列表中
- 5.ZK服务端监听到数据或路径变化,就会将这个消息发送给(listener)线程
- 6.
listener线程内部调用了process方法去做相应的操做

- 1.首先要有一个
-
3.常见的监听
- 1.监听节点数据的变化(get path [watch])
- 2.监听子节点增减的变化(ls path [watch])
10.11监听器实践
-
1.注册节点值变化监听器
注意:注册一次只能监听一次,想要再次监听,需要再次注册
get -w path
-
2.注册节点的子节点变化监听器(路径变化)
注意:注册一次只能监听一次,想要再次监听,需要再次注册
ls -w path
10.12写入流程
- 1.写入流程请求发送给Leader节点(只有Leader有写权限,follower只有读权限)

- 2.写入流程请求发送给Follower节点

11.客户端API操做
python-zookeeper:https://blog.csdn.net/github_30641423/article/details/109561587


















