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最后更新的事务zxid
mtime
:znode最后修改的毫秒数(从1970年开始)pZxid
:znode最后更新的子节点事务zxid
cversion
: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
永久节点(不带序号),并且初始化数据为:diaochan
create /wangzherongyao/fashi diaochan
-
在
wangzherongyao
节点下创建一个zhanshi
永久节点(带序号),并且初始化数据为:yase
create -s /wangzherongyao/zhanshi "yase"
-
在
wangzherongyao
节点下创建一个zhanshi
永久节点(带序号),并且初始化数据为:lixin
create -s /wangzherongyao/zhanshi "lixin"
- 永久节点不会因为断开连接而自动删除
- 如果不带序号,则本次创建永久节点
zhanshi
时就会报错该节点已存在
-
在
wangzherongyao
节点下创建一个sheshou
临时节点(不带序号),并且初始化数据为:luban
create -e /wangzherongyao/sheshou "luban"
-
在
wangzherongyao
节点下创建一个sheshou
临时节点(带序号),并且初始化数据为:houyi
create -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
的值为:mengya
set /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