一 Zookeeper概念
1 集中式到分布式
1.1 单机架构
一个系统业务量很小的时候所有的代码都放在一个项目中就好了, 然后这个项目部署在一台服务器上,整个项目所有的服务都由这台 服务器提供。
缺点:
- 服务性能存在瓶颈
- 不可伸缩性
- 代码量庞大,系统臃肿,牵一发动全身
- 单点故障问题
1.2 集群架构
单机处理到达瓶颈的时候,你就把单机复制几份,这样就构成了一 个集群。
集群存在的问题:
当你的业务发展到一定程度的时候,你会发现一个问题无论怎么增加节点,貌似整个集群性能的提升效果并不明显了。这时候,你就需要使用分布式架构了。
1.3 什么是分布式
分布式架构就是将一个完整的系统,按照业务功能,拆分成一个个独立的子系统,在分布式结构中,每个子系统就被称为“服务”。这些子系统能够独立运行在web容器中,它们之间通过RPC方式通信。
分布式的优势:
- 系统之间的耦合度大大降低,可以独立开发、独立部署、独立测试,系统与系统之间的边界非常明确,排错也变得相当容易,开发效率大大提升。
- 系统之间的耦合度降低,从而系统更易于扩展。我们可以针对性地扩展某些服务。
- 服务的复用性更高。比如,当我们将用户系统作为单独的服务后,该公司所有的产品都可以使用该系统作为用户系统,无需重复开发。
1.4 三者区别
总结:
将一套系统拆分成不同子系统部署在不同服务器上(这叫分布式),然后部署多个相同的子系统在不同的服务器上(这叫集群)
。
集群:多个人在一起做同样的事 。
分布式 :多个人在一起做不同的事 。
2 CAP定理
分布式系统正变得越来越重要,大型网站几乎都是分布式的。分布式系统的最大难点,就是各个节点的状态如何同步。CAP 定理是这方面的基本定理,也是理解分布式系统的起点。
分布式系统的三个指标
- Consistency(一致性)
- Availability (可用性)
- Partition tolerance (分区容错性)
它们的第一个字母分别是 C、A、P。
这三个指标不可能同时做到。这个结论就叫做 CAP 定理。
2.1 分区容错性
大多数分布式系统都分布在多个子网络。每个子网络就叫做一个 区。分区容错的意思是,区间通信可能失败。比如,一台服务器放在中国,另一台服务器放在美国,这就是两个区,它们之间可能无法通信。
结论:分区容错无法避免,因此可以认为 CAP 的 P 总是成立。CAP 定 理告诉我们,剩下的 C 和 A 无法同时做到。
2.2 一致性
写操作之后的读操作,必须返回该值。举例来说,某条记录是 v0, 用户向 G1 发起一个写操作,将其改为 v1。
接下来,用户的读操作就会得到 v1。这就叫一致性。
问题是,用户有可能向 G2 发起读操作,由于 G2 的值没有发生变 化,因此返回的是 v0。G1 和 G2 读操作的结果不一致,这就不满足一致性了。
为了让 G2 也能变为 v1,就要在 G1 写操作的时候,让 G1 向 G2 发 送一条消息,要求 G2 也改成 v1。
2.3 可用性
只要收到用户的请求,服务器就必须给出回应。
解释:用户可以选择向 G1 或 G2 发起读操作。不管是哪台服务器,只要收到请求,就必须告诉用户,到底是 v0 还是 v1,否则就不满足可用性。
2.4 一致性和可用性的矛盾
解释:如果保证 G2 的一致性,那么 G1 必须在写操作时,锁定 G2 的 读操作和写操作。只有数据同步后,才能重新开放读写。锁定期间,G2 不能读写,没有可用性。
2.5 一致性和可用性如何选择
一致性 :
特别是涉及到重要的数据,就比如钱,商品数量,商品价格。
可用性 :
网页的更新不是特别强调一致性,短时期内,一些用户拿到老版本,另一些用户拿到新版本,问题不会特别大。
3 什么是Zookeeper
3.1 分布式架构
多个节点协同问题:
-
每天的定时任务由谁哪个节点来执行?
-
RPC调用时的服务发现?
-
如何保证并发请求的幂等
这些问题可以统一归纳为多节点协调问题,如果靠节点自身进行协调这是非常不可靠的,性能上也不可取。必须由一个独立的服务做协调工作,它必须可靠,而且保证性能。
一个应用程序,涉及多个进程协作时,业务逻辑代码中混杂有大量复杂的进程协作逻辑。
上述多进程协作逻辑,有 2 个特点: 处理复杂, 处理逻辑可重用
因此,考虑将多进程协作的共性问题拎出,作为基础设施,让 RD 更加专注业务逻辑开发,即:
3.2 Zookeeper从何而来
ZooKeeper最早起源于雅虎研究院的一个研究小组。在当时,研究 人员发现,在雅虎内部很多大型系统基本都需要依赖一个类似的系 统来进行分布式协调,但是这些系统往往都存在分布式单点问题。
解决:雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架,以便让开发人员将精力集中在处理业务逻辑上。
3.3 Zookeeper介绍
ZooKeeper是一个开放源代码的分布式协调服务。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。
说明:Zookeeper顾名思义就是动物园管理员。 因为Hadoop生态各 个项目都是动物得图标。 所以很符合管理员得形象。
4 应用场景
4.1 数据发布/订阅
数据发布/订阅的一个常见的场景是配置中心,发布者把数据发布到 ZooKeeper 的一个或一系列的节点上,供订阅者进行数据订阅,达到动态获取数据的目的。
ZooKeeper 采用的是推拉结合的方式。
推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知
拉: 客户端获得通知后,然后主动到服务端拉取最新的数据
实现的思路
mysql.driverClassName=com.mysql.jdbc.Driver
dbJDBCUrl=jdbc:mysql://127.0.0.1/runzhlliu
username=root
password=123456
具体流程:
- 把配置信息写到一个 Znode 上,例如 /DBConfiguration
- 客户端启动初始化阶段读取服务端节点的数据,并且注册一个数据变更的 Watcher
- 配置变更只需要对 Znode 数据进行 set 操作,数据变更的通知会发送到客户端,客户端重新获取新数据,完成配置动态修改
4.2 负载均衡
负载均衡是一种手段,用来把对某种资源的访问分摊给不同的设备,从而减轻单点的压力。
实现的思路:
- 首先建立 Servers 节点,并建立监听器监视 Servers 子节点的状态(用于在服务器增添时及时同步 当前集群中服务器列表)
- 在每个服务器启动时,在 Servers 节点下建立临时子节点 Worker Server,并在对应的字节点下存 入服务器的相关信息,包括服务的地址,IP,端口等等
- 可以自定义一个负载均衡算法,在每个请求过来时从 ZooKeeper 服务器中获取当前集群服务器列表,根据算法选出其中一个服务器来处理请求
4.3 命名服务
命名服务就是提供名称的服务。ZooKeeper 的命名服务有两个应用方面。
功能:
提供类 JNDI 功能,可以把系统中各种服务的名称、地址以及目录信息存放在 ZooKeeper, 需要的时候去 ZooKeeper 中读取
制作分布式的序列号生成器
4.4 分布式协调/通知
分布式协调/通知服务是分布式系统中不可缺少的一个环节,是将不同的分布式组件有机结合起来的关键所在。对于一个在多台机器上部署运行的应用而言,通常需要一个协调者(Coordinator)来控制整个系统的运行流程。
5 为什么选择Zookeeper
随着分布式架构的出现,越来越多的分布式应用会面临数据一致性问题。很遗憾的是,在解决分布式数据一致性上,除了ZooKeeper 之外,目前还没有一个成熟稳定且被大规模应用的解决方案。
主要:ZooKeeper无论从易用性还是稳定性上来说,都已经达到了一 个工业级产品的标准。
ZooKeeper是免费的,你无须为它支付任何费用。这点对于一个小 型公司,尤其是初创团队来说,无疑是非常重要的。
广泛应用:
最后,ZooKeeper已经得到了广泛的应用。诸如Hadoop、 HBase、Storm、kafka等越来越多的大型分布式项目都将 Zookeeper作为核心组件。
6 基本概念
6.1 集群角色
通常在分布式系统中,构成一个集群的每一台机器都有自己的角色,最典型的集群模式就是Master/Slave模式(主备模式)。在这种模式中,我们把能够处理所有写操作的机器称为Master机器,把所有通过异步复制方式获取最新数据,并提供读服务的机器称为Slave 机器。
概念颠覆:
而在ZooKeeper中,这些概念被颠覆了。它没有沿用传统的 MasterlSlave概念,而是引入了Leader、Follower和 Observer 三种角色。
6.2 数据节点(znode)
在谈到分布式的时候,我们通常说的“节点”是指组成集群的每一台机器。
在ZooKeeper中节点分为两类:
- 第一类同样是指构成集群的机器,我们称之为机器节点
- 第二类则是指数据模型中的数据单元,我们称之为数据节点——ZNode。
ZooKeeper将所有数据存储在内存中,数据模型是一棵树。
6.3 Watcher监听机制
Watcher(事件监听器),是ZooKeeper 中的一个很重要的特性。
注意:ZooKeeper 允许用户在指定节点上注册一些Watcher,并且在 一些特定事件触发的时候,ZooKeeper 服务端会将事件通知到感兴趣的客户端上去,该机制是ZooKeeper实现分布式协调服务的重要特性。
6.4 ACL权限控制
ZooKeeper 采用ACL (Access Control Lists)策略来进行权限控制,类似于UNIX文件系统的权限控制。ZooKeeper定义了如下5种权限。
- CREATE:创建子节点的权限
- READ:获取节点数据和子节点列表的权限
- WRITE:更新节点数据的权限
- DELETE:删除子节点的权限
- ADMIN:设置节点ACL的权限
注意: create和delete这两种权限都是针对子节点的权限控制。
二 Zookeeper运行部署
1 伪集群安装
下载Zookeeper
下载具体版本
解压zookeeper
tar -zxvf apache-zookeeper-3.7.3.tar.gz -C /usr/local
修改配置文件
进入zookeeper的安装目录的conf目录
cd /usr/local/zookeeper/config
cp zoo_sample.cfg zoo.cfg
修改zoo.cfg
# The number of milliseconds of each tick
tickTime=2000initLimit=10
syncLimit=5
dataDir=/usr/local/zookeeper/zkdata
dataLogDir=/usr/local/zookeeper/zklogs
clientPort=2181
创建数据持久化目录
mkdir /usr/local/zookeeper/zkdata
mkdir /usr/local/zookeeper/zklogs
配置JDK环境
vim /etc/profile
export JAVA_HOME=/usr/local/jdk
export PATH=$PATH:$JAVA_HOME/bin
生效环境变量
source /etc/profile
启动zookeeper服务
zkServer.sh start
查看Zookeeper运行状态
zkServer.sh status
2 集群安装
环境准备
服务器1 192.168.66.101
服务器2 192.168.66.102
服务器3 192.168.66.103
解压zookeeper
tar -zxvf apache-zookeeper-3.6.3.tar.gz -C /usr/local
修改配置文件
进入zookeeper的安装目录的conf目录
cd /usr/local/zookeeper/config
cp zoo_sample.cfg zoo.cfg
修改zoo.cfg
# 心跳检查的时间 2秒
tickTime=2000
initLimit=10
# ZK Leader 和follower 之间通讯的次数,总时间5*2=10秒
syncLimit=5
# 存储内存中数据快照的位置,如果不设置参数,更新事务日志将被存储到默认位置。
dataDir=/usr/local/zookeeper/zkdata
# ZK 服务器端的监听端口
clientPort=2181
#autopurge.purgeInterval=1
server.1=192.168.66.101:2888:3888
server.2=192.168.66.102:2888:3888
server.3=192.168.66.103:2888:3888
创建数据持久化目录
对3台节点,都创建zkdata目录 。
mkdir /usr/local/zookeeper/zkdata
在工作目录中生成myid文件
第一台机器上: echo 1 >
/usr/local/zookeeper/zkdata/myid
第二台机器上: echo 2 >
/usr/local/zookeeper/zkdata/myid
第三台机器上: echo 3 >
/usr/local/zookeeper/zkdata/myid
启动zookeeper集群
zookeeper没有提供自动批量启动脚本,需要手动一台一台地起 zookeeper进程 在每一台节点上,运行命令:
bin/zkServer.sh start
注意:
启动后,用jps应该能看到一个进程:QuorumPeerMain。光有 进程不代表zk已经正常服务,需要用命令检查状态: bin/zkServer.sh status 能看到角色模式:为leader或 follower,即正常了。
3 服务管理
脚本 | 说明 |
---|---|
zkCleanup | 清理Zookeeper历史数据,包括事务日志文件和快照数据文件 |
zkCli | Zookeeper的简易客户端 |
zkEnv | 设置Zookeeper的环境变量 |
zkServer | Zookeeper服务器的启动、停止和重启脚本 |
配置环境变量
修改文件 vim /etc/profile
export ZOOKEEPER_HOME=/usr/local/zookeeper
export PATH=$PATH:$ZOOKEEPER_HOME/sbin
启动服务
sh zkServer.sh start
停止服务
sh zkServer.sh stop
查看zookeeper状态
sh zkServer.sh status
设置一键启动/一键停止脚本
编写一键启停脚本 vim zkStart-all.sh
#验证传入的参数
# $# 启动脚本时携带的参数个数
# -ne 不等于
if [ $# -ne 1 ];then
echo "无效参数,用法为: {start|stop|restart|status}"
exit
fi
#遍历所有节点
for host in 192.168.66.101 192.168.66.102 192.168.66.103
do
echo "========== $host 正在 $1 ========="
#发送命令给目标机器
ssh $host "source /etc/profile; /usr/local/apache-zookeeper-3.7.0-bin/bin/zkServer.sh $1"
done
三 Zookeeper系统模型
1 数据模型
在Zookeeper中,可以说 Zookeeper中的所有存储的数据是由 znode组成的,节点也称为 znode,并以 key/value 形式存储数据。
1.1 树
介绍:整体结构类似于 linux 文件系统的模式以树形结构存储。其中根 路径以 / 开头。
1.2 保存数据
注意: 以 key/value 形式存储数据。key就是znode的节点路径,比如 /java , /server。
2 节点特性
znode节点类型
ZooKeeper 节点是有生命周期的,这取决于节点的类型。节点类型 可以分为持久节点、临时节点,以及有序节点,具体在节点创建过程中,一般是组合使用,可以生成以下 4 种节点类型。
2.1 持久节点
持久节点是zookeeper中最常见的一种节点类型。所谓持久节点, 是指改数据节点被创建后,就会一直存在与zookeeper服务器上, 直到有删除操作来主动清除这个节点。
示例:
/java spring
/lxx sanhan
2.2 持久顺序节点
这类节点的基本特性和上面的节点类型是一致的。额外的特性是, 在ZK中,每个父节点会为他的第一级子节点维护一份时序,会记录 每个子节点创建的先后顺序。
示例:
/java00000000000001 spring
/baizhan00000000000001 itbaizhan
2.3 临时节点
- 从名称上可以看出该节点的一个最重要的特性就是临时性。
- 所谓临时性是指,如果将节点创建为临时节点,那么该节点数据不会一直存储在 ZooKeeper 服务器上。
区别:
和持久节点不同的是,临时节点的生命周期和客户端会话绑定。也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉。注意,这里提到的是会话失效,而非连接断开。另外,在临时节点下面不能创建子节点。
2.4 临时顺序节点
临时顺序节点的基本特性和临时节点是一致的,同样是在临时节点 的基础上,添加了顺序的特性。
示例:
/baizhan0000000000000001 itbaizhan
/baizhan0000000000000002 itbaizhan
/baizhan0000000000000003 itbaizhan
3 客户端命令行
3.1 创建
创建ZK节点
语法结构:
create [-s] [-e] path data acl
参数:
-s:顺序节点
-e:临时节点
默认情况下,不添加-s或者-e参数的,创建的是持久节点。
示例:
[zk: localhost:2181(CONNECTED) 0]create /zk-book lxx
3.2 读取
读取节点信息ls命令和get命令。
ls命令
语法结构:
ls path [watch]
示例:
ls /
注意: 第一次部署的ZooKeeper集群,默认在根节点“1”下面有一个叫 作/zookeeper的保留节点。
get命令
使用get命令,可以获取zookeeper指定节点的数据内容和属性信息。
语法格式:
get path [watch]
示例:
get /zk-book
3.3 更新
使用set命令,可以更新指定节点的数据内容。
语法结构:
set path data [version]
参数: data就是要更新的新内容。注意,set命令后面还有一个version 参数,在ZooKeeper 中,节点的数据是有版本概念的,这个参数用于指定本次更新操作是基于ZNode的哪一个数据版本进行 的。
3.4 删除
删除zookeeper上的指定节点。
语法结构:
delete path [version]
示例:
create /zk-book 123
create /zk-book/child 12345
delete /zk-book
注意: 如果节点包含子节点就报错。
4 节点数据信息
4.1 节点的状态结构
每个节点都有属于自己的状态信息,这就很像每个人的身份信息一 样。
语法结构:
[zk: localhost:2181(CONNECTED) 15] stat /a
cZxid = 0x300000014
ctime = Thu Dec 30 15:05:07 CST 2021
mZxid = 0x300000014
mtime = Thu Dec 30 15:05:07 CST 2021
pZxid = 0x300000015
cversion = 1
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 1
numChildren = 1
4.2 查看节点类型
5 Watcher监听机制
ZooKeeper 提供了分布式数据的发布/订阅功能。一个典型的发布/ 订阅模型系统定义了一种一对多的订阅关系,能够让多个订阅者同时监听某一个主题对象,当这个主题对象自身状态变化时,会通知所有订阅者,使它们能够做出相应的处理。
注意:
在ZooKeeper中,引入了Watcher机制来实现这种分布式的通知功能。ZooKeeper允许客户端向服务端注册一个 Watcher监听,当服务端的一些指定事件触发了这个Watcher,那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。
监听机制
- 监听节点变化
语法结构:
ls -w path
参数: 命令如果使用watch,那么监听的是节点的变化,而不是值的变化。
- 监听节点的值的变化
语法结构:
get -w path
参数: watch监听机制只能够使用一次,如果下次想要使用,必须重新监听,就比如ls -w path命令,只能监听节点路径的改变一 次,如果还想监听,那么需要再执行一次ls -w path命令。
6 Watcher事件机制原理剖析
在ZooKeeper中,接口类Watcher 用于表示一个标准的事件处理器,其定义了事件通知相关的逻辑,包含KeeperState和 EventType两个枚举类,分别代表了通知状态和事件类型,同时定义了事件的回调方法: process (WatchedEvent event)。
6.1 Watcher接口
通知状态
- SyncConnected 连接成功
- Disconnected 连接失败
- AuthFailed 认证失败
- Expired 会话超时
事件类型
- None 当zookeeper客户端连接状态发生变更是 SyncConnected Disconnected AuthFailed Expired
- NodeCreated 创建节点
- NodeDeleted 节点删除
- NodeDataChanged 数据发生改变
- NodeChildrenChanged 子节点数据发生改变
6.2 Watcher 特性总结
一次性
无论是服务端还是客户端,一旦一个 Watcher 被触发,ZooKeeper 都会将其从相应的存储中移除。因此,在 Watcher 的使用上,需要 反复注册。这样的设计有效地减轻了服务端的压力。
客户端串行执行
客户端 Watcher 回调的过程是一个串行同步的过程,这为我们保证了顺序,同时,需要注意的一点是,一定不能因为一个 Watcher 的 处理逻辑影响了整个客户端的 Watcher 回调。
轻量
WatcherEvent 是 ZooKeeper 整个 Watcher 通知机制的最小通知 单元,这个数据结构中只包含三部分内容:通知状态、事件类型和 节点路径。
7 权限控制 ACL
在ZooKeeper的实际使用中,我们的做法往往是搭建一个共用的 ZooKeeper集群,统一为若干个应用提供服务。在这种情况下,不同的应用之间往往是不会存在共享数据的使用场景的,因此需要解决不同应用之间的权限问题。
ACL 权限控制
- 权限模式(Schema)
- 授权对象(ID)
- 权限(Permission)`
参数:
- ZooKeeper的权限控制是基于每个znode节点的,需要对每个节点设置权限
- 每个znode支持设置多种权限控制方案和多个权限
- 子节点不会继承父节点的权限,客户端无权访问某节点,但可能可以访问它的子节点
例子:
setAcl /test2 ip:128.0.0.1:crwda
7.1 schema(授权策略)
ZooKeeper内置了一些权限控制方案,可以用以下方案为每个节点设置权限:
方案 | 描述 |
---|---|
world | 只有一个用户:anyone,代表所有人(默认) |
ip | 使用IP地址认证 |
auth | 使用已添加认证的用户认证 |
digest | 使用“用户名:密码”方式认证 |
7.2 id(授权对象)
授权对象ID是指,权限赋予的用户或者一个实体,例如:IP 地址或 者机器。授权模式 schema 与 授权对象 ID 之间关系:
权限模式 | 授权对象 |
---|---|
World | 只有一个ID:“anyone” |
IP | 通常是一个IP地址或是IP段,例如“192.168.66.101” |
Digest | 自定义,通常是“username:BASE64(SHA-1(username:password))” |
Super | 与Digest模式一致 |
7.3 Permission(授权权限)
权限 | ACL简写 | 描述 |
---|---|---|
CREATE | c | 可以创建子节点 |
DELETE | d | 可以删除子节点(仅下一级节点) |
READ | r | 可以读取节点数据及显示子节点列表 |
WRITE | w | 可以设置节点数据 |
ADMIN | a | 可以设置节点访问控制列表权限 |
7.4 权限相关命令
命令 | 描述 |
---|---|
getAcl | 读取ACL权限 |
setAcl | 设置ACL权限 |
addauth | 添加认证用户 |
7.5 实战
World方案
语法格式:
setAcl <path> world:anyone:<acl>
客户端实例
[zk: localhost:2181(CONNECTED) 0] create /node1 1
Created /node1
[zk: localhost:2181(CONNECTED) 1] getAcl /node1
'world,'anyone #默认为world方案
: cdrwa #任何人都拥有所有权限
IP方案
语法格式:
setAcl <path> ip:<ip>:<acl>
参数:
可以是具体IP也可以是IP/bit格式,即IP转换为二进制,匹配前bit位,如192.168.0.0/16匹 配192.168…
客户端实例
#创建节点
[zk: localhost:2181(CONNECTED) 0] create /node2 1
Created /node2
#设置权限
#设置IP:192.168.66.101 拥有所有权限
[zk: localhost:2181(CONNECTED) 1] setAcl /node2 ip:192.168.100.101:cdrwa
#使用IP非 192.168.66.101 的机器
[zk: localhost:2181(CONNECTED) 0] get /node2
org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /node2 #没有权限
Auth方案
语法格式:
setAcl <path> auth:<user>:<acl>
添加认证用户
addauth digest <user>:<password>
客户端实例
#创建节点
[zk: localhost:2181(CONNECTED) 0] create /node3 1
Created /node3
#添加认证用户
[zk: localhost:2181(CONNECTED) 1] addauth digest lxx:123456
#设置权限
[zk: localhost:2181(CONNECTED) 2] setAcl /node3 auth:lxx:cdrwa
#获取权限
[zk: localhost:2181(CONNECTED) 3] getAcl /node3
'digest,'lxx:UvJWhBril5yzpEiA2eV7bwwhfLs=
: cdrwa
刚才已经添加认证用户,可以直接读取数据,断开会话重连需要重 新addauth添加认证用户
[zk: localhost:2181(CONNECTED) 0] get /node3
org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /node3
[zk: localhost:2181(CONNECTED) 1] addauth digest lxx:123456
[zk: localhost:2181(CONNECTED) 2] get /node3
1
Digest方案
语法格式:
setAcl <path> digest:<user>:<password>:<acl>
这里的密码是经过SHA1及BASE64处理的密文,在SHELL中可以通 过以下命令计算:
echo -n <user>:<password> | openssl dgst - binary -sha1 | openssl base64
先来计算一个密文
echo -n lxx:123456 | openssl dgst -binary -sha1 | openssl base64
2zPICPbLzitTX5NMmjFgKGS7C0M=
客户端实例
#创建节点
[zk: localhost:2181(CONNECTED) 0] create /node4 1
Created /node4
#使用是上面算好的密文密码添加权限:
[zk: localhost:2181(CONNECTED) 1] setAcl /node4 digest:lxx:2zPICPbLzitTX5NMmjFgKGS7C0M=:cdrwa
#获取节点数据没有权限
[zk: localhost:2181(CONNECTED) 3] get /node4
Authentication is not valid : /node4
#添加认证用户
[zk: localhost:2181(CONNECTED) 4] addauth digest lxx:123456
#成功读取数据
[zk: localhost:2181(CONNECTED) 5] get /node4
1
四 JAVA客户端操作
1 原生api操作Zookeeper
利用Zookeeper官方的原生java api进行连接,然后演示一些创建、 删除、修改、查询节点的操作。
引入依赖
<dependencies>
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.8</version>
</dependency>
</dependencies>
创建会话
/**
* 创建一个 Zookeeper 的实例
* 此处为一个集群,Zookeeper 的 ip 之间用逗号隔开
*
* 参数解释:
* param 1 - Zookeeper 的实例 ip ,此处是一个集群,所以配置了多个 ip,用逗号隔开
* param 2 - session 过期时间,单位秒(1000)
* param 3 - 监视者,用于获取监听事件(MyWatch)
*/
ZooKeeper zooKeeper = new ZooKeeper("192.168.1.108:2181", 5000, null);
创建节点
private void createNodeSync() throws
KeeperException, InterruptedException {
String path = "/poype_node";
/*
*znode名称
*节点数据
*设置权限
*znode类型
*
*/
String nodePath = zooKeeper.create(path,"123".getBytes(),
ZooDefs.Ids.OPEN_ACL_UNSAFE,
CreateMode.PERSISTENT);
System.out.println(nodePath);
}
znode 类型有四种
-
PERSISTENT - 持久化目录节点,客户端与zookeeper断开连接后,该节点依旧存在
-
PERSISTENT_SEQUENTIAL - 持久化,并带有序列号
-
EPHEMERAL - 临时目录节点,客户端与zookeeper断开连接后,该节点被删除
-
EPHEMERAL_SEQUENTIAL - 临时,并带有序列号
删除节点
同步方式删除一个节点:
private void deleteSync() throws
KeeperException, InterruptedException {
zooKeeper.delete("/node_1", -1);
}
读取数据
private void getDataSync() throws
KeeperException, InterruptedException {
Stat stat = new Stat();
// getData的返回值是该节点的数据值,节点的状态信息会赋值给stat对象
byte[] data = zooKeeper.getData("/node_1",true, stat);
System.out.println(new String(data));
System.out.println(stat);
}
参数:
znode 名称 (/zoo)
监视者,用于获取监控事件 (MyWatch)
Zookeeper 实例信息和数据信息 (stat)
更新数据
Stat stat = zooKeeper.setData("/poype_node2","poype5211314".getBytes(), -1);
参数:
param1:znode名称
param2:节点数据
param3:该节点的版本
检测节点是否存在
private void existSync() throws
KeeperException, InterruptedException {
Stat stat = zooKeeper.exists("/poype_node2", true);
System.out.println(stat);
}
参数:
param1:znode 名称 (/zoo) param2:
监视者,用于获取监控事件 (MyWatch)
注册监听getChilren
通过zkCli.getchildren(“/”,new watch()){}来注册监听,监听的是整 个根节点,但是这个监听只能监听一次。线程休眠是为了让监听等待 事件发生,不然会随着程序直接运行完。
public class WatchDemo {
static List<String> children = null;
public static void main(String[] args) throws IOException, KeeperException,
InterruptedException {
ZooKeeper zkCli = new ZooKeeper("192.168.50.183:2181,192.168.50.184:2181,192.168.50.185:2181",
3000, new Watcher() {
//监听回调
@Override
public void process(WatchedEvent event) {
System.out.println("正在监听中.....");
}
});
//监听目录
children = zkCli.getChildren("/", new Watcher() {
@Override
public void process(WatchedEvent event) {
System.out.println("监听路径为:" + event.getPath());
System.out.println("监听的类型为:" + event.getType());
System.out.println("目录被修改了!!!");
for (String c : children) {
System.out.println(c);
}
}
});
Thread.sleep(Long.MAX_VALUE);
}
}
注册监听getData
getData监听的为一个节点,同样只监听一次,返回的是该节点的内容。
public class WatchDemo {
public static void main(String[] args)
throws IOException, KeeperException,
InterruptedException {
ZooKeeper zkCli = new
ZooKeeper("192.168.50.183:2181,192.168.50.184:2181, 192.168.50.185:2181 ", 3000,
new Watcher() {
//监听回调
@Override
public void process(WatchedEvent event) {
}
});
byte[] data =
zkCli.getData("/hunter", new Watcher() {
//监听的具体内容
@Override
public void process(WatchedEvent
event) {
System.out.println("监听路径 为:" + event.getPath());
System.out.println("监听的类型为:" + event.getType());
System.out.println("数据被修改了!!!");
}
}, null);
System.out.println(new String(data));
Thread.sleep(Long.MAX_VALUE);
}
}
2 zkclient库操作Zookeeper
使用zookeeper遇到问题:
-
重复注册watcher
-
session失效重连
-
异常处理(删除节点不能有子节点,新增节点必须有父节点等)
zkclient是Github上一个开源的Zookeeper客户端,在Zookeeper 原生 API接口之上进行了包装,是一个更加易用的Zookeeper客户 端。同时Zkclient在内部实现了诸如Session超时重连,Watcher反 复注册等功能,从而提高开发效率。
添加依赖
<dependency>
<groupId>com.101tec</groupId>
<artifactId>zkclient</artifactId>
<version>0.10</version>
</dependency>
创建会话
String connStr = "192.168.66.101:2181";
ZkClient zk = new ZkClient(connStr);
创建节点
String res = zk.create("/root", "baizhan",CreateMode.PERSISTENT);
修改节点数据
zk.writeData("/root", "itbaizhan");
获取节点数据
String res = zk.readData("/root");
删除节点
zk.delete("/root");
注册数据监听
zk.subscribeDataChanges("/root/ghz", new IZkDataListener() {
@Override
public void handleDataDeleted(String arg0) throws Exception {
System.err.println("数据删除:" + arg0);
}
@Override
public void handleDataChange(String arg0, Object arg1) throws Exception {
System.err.println("数据修改:" + arg0 + "------" + arg1);
}
});
注册节点监听
zk.subscribeChildChanges("/root", (arg0, arg1) -> {
System.err.println("子节点发生变化:" + arg0);
arg1.forEach(f -> {
System.out.println("content:" + f);
});
});
3 Apache Curator操作Zookeeper
Curator是 Netflix公司开源的一套ZooKeeper客户端框架。和 ZkClient一样,Curator解决了很多ZooKeeper客户端非常底层的细 节开发工作,包括连接重连、反复注册Watcher和 NodeExistsException异常等,目前已经成为了Apache的顶级项目, 是全世界范围内使用最广泛的ZooKeeper客户端之一。
Curator包
- curator-framework:对zookeeper的底层api的一些封装。
- curator-client:提供一些客户端的操作,例如重试策略等。
- curator-recipes:封装了一些高级特性,如:Cache事件监听、选举、分布式锁、分布式计数 器、分布式Barrier等。
添加Maven依赖
<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>4.2.0</version>
</dependency>
创建会话
String connStr = "192.168.18.128:2181";
CuratorFramework cur = CuratorFrameworkFactory.builder()
.connectString(connStr)
.connectionTimeoutMs(5000)
.retryPolicy(new ExponentialBackoffRetry(1000,3))
.build();
cur.start();//连接
创建节点
cur.create().withMode(CreateMode.PERSISTENT)
.forPath("/root","baizhan".getBytes());
删除数据节点
cur.delete().forPath("/root");
注意: 此方法只能删除叶子节点,否则会抛出异常
删除一个节点,并且递归删除其所有的子节点
cur.delete().deletingChildrenIfNeeded().forPath("/root");
删除一个节点,强制指定版本进行删除
cur.delete().withVersion(10086).forPath("path");
删除一个节点,强制保证删除
cur.delete().guaranteed().forPath("path");
注意: guaranteed()接口是一个保障措施,只要客户端会话有效,那 么Curator会在后台持续进行删除操作,直到删除节点成功。
注意:上面的多个流式接口是可以自由组合的,例如:
cur.delete().guaranteed().deletingChildrenIfNeeded()
.withVersion(10086).forPath("/root");
读取数据节点数据
读取一个节点的数据内容
cur.getData().forPath("/root");
注意: 此方法返的返回值是byte[ ];
读取一个节点的数据内容,同时获取到该节点的stat
Stat stat = new Stat();
client.getData().storingStatIn(stat).forPath("path");
更新数据节点数据
更新一个节点的数据内容
client.setData().forPath("path","data".getBytes());
注意:该接口会返回一个Stat实例;
更新一个节点的数据内容,强制指定版本进行更新
client.setData().withVersion(10086).forPath("path","data".getBytes());
检查节点是否存在
client.checkExists().forPath("path");
注意: 该方法返回一个Stat实例,用于检查ZNode是否存在的操作. 可 以调用额外的方法(监控或者后台处理)并在最后调用 forPath() 指定 要操作的ZNode
获取某个节点的所有子节点路径
client.getChildren().forPath("path");
五 Zookeeper高级
1 四字命令
之前使用stat命令来验证ZooKeeper服务器是否启动成功,这里的 stat命令就是ZooKeeper 中最为典型的命令之一。ZooKeeper中有 很多类似的命令,它们的长度通常都是4个英文字母,因此我们称之 为“四字命令”。
添加配置
vim zoo.cfg
4lw.commands.whitelist=*
四字命令
conf
输出Zookeeper相关服务的详细配置信息,如客户端端口,数据存 储路径、最大连接数、日志路径、数据同步端口、主节点推举端 口、session超时时间等等。
语法结构:
echo conf| nc localhost 2181
注意: 注意,conf命令输出的配置信息仅仅是输出一些最基本的配置 参数。另外,conf命令会根据当前的运行模式来决定输出的信 息。如果是单机模式(standalone), 就不会输出诸如 initLimit.syncLimit、electionAlg 和electionPort等集群相关的 配置信息。
cons
cons 命令用于输出当前这台服务器上所有客户端连接的详细信息, 包括每个客户端的客户端IP、会话ID和最后一次与服务器交互的操 作类型等。
语法结构:
echo cons | nc localhost 2181
ruok
ruok命令用于输出当前ZooKeeper服务器是否正在运行。该命令的 名字非常有趣,其谐音正好是“Are you ok”。执行该命令后,如果 当前ZooKeeper服务器正在运行,那么返回“imok”, 否则没有任何响应输出。
语法结构:
echo ruok | nc localhost 2181
stat
stat命令用于获取ZooKeeper服务器的运行时状态信息,包括基本的 ZooKeeper版本、打包信息、运行时角色、集群数据节点个数等信 息,另外还会将当前服务器的客户端连接信息打印出来。
语法结构:
echo stat | nc localhost 2181
注意: 除了一些基本的状态信息外,stat命令还会输出一些服务器的统 计信息,包括延迟情况、收到请求数和返回的响应数等。注 意,所有这些统计数据都可以通过srst命令进行重置。
mntr
列出集群的关键性能数据,包括zk的版本、最大/平均/最小延迟 数、数据包接收/发送量、连接数、zk角色(Leader/Follower)、 node数量、watch数量、临时节点数。
语法结构:
echo mntr | nc localhost 2181
2 选举机制
核心选举原则
- Zookeeper集群中只有超过半数以上的服务器启动,集群才能正常工作;
- 在集群正常工作之前,myid小的服务器给myid大的服务器投票,直到集群正常工作,选出 Leader;
- 半数机制;
选举机制流程
- 服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息, 服务器1的状态一直属于Looking(选举状态)。
- 服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务 器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。
- 服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以 服务器3胜出,此时投票数正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。
- 服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为小弟。
- 服务器5启动,后面的逻辑同服务器4成为小弟。
选择机制中的概念
Serverid:服务器ID
比如有三台服务器,编号分别是1,2,3。
编号越大在选择算法中的权重越大。
Zxid:数据ID
服务器中存放的最大数据ID.
值越大说明数据越新,在选举算法中数据越新权重越大。
Epoch:逻辑时钟
或者叫投票的次数,同一轮投票过程中的逻辑时钟值是相同的。每 投完一次票这个数据就会增加,然后与接收到的其它服务器返回的 投票信息中的数值相比,根据不同的值做出不同的判断。
出当前这台服务器上所有客户端连接的详细信息, 包括每个客户端的客户端IP、会话ID和最后一次与服务器交互的操 作类型等。