Zookeeper笔记
Zookeeper
1)初识 Zookeeper
1.1)Zookeeper概念
Zookeeper 是 Apache Hadoop 项目下的一个子项目,是一个树形目录服务。
Zookeeper 翻译过来就是 动物园管理员,他是用来管 Hadoop(大象)、Hive(蜜蜂)、Pig(小 猪)的管理员。简称zk
Zookeeper 是一个分布式的、开源的分布式应用程序的协调服务。
Zookeeper 提供的主要功能包括:
配置管理
分布式锁
集群管理
2)Zookeeper 入门
2.1)概述
Zookeeper 是一个开源的分布式的,为分布式框架提供协调服务的Apache 项目。
Zookeeper工作机制
Zookeeper从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。
2.2)特点
Zookeeper:一个领导者(Leader),多个跟随者(Follower)组成的集群。
集群中只要有半数以上节点存活,Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
全局数据一致:每个Server保存一份相同的数据副本,Client无论连接到哪个Server,数据都是一致的。
更新请求顺序执行,来自同一个Client的更新请求按其发送顺序依次执行。
数据更新原子性,一次数据更新要么成功,要么失败。
实时性,在一定时间范围内,Client能读到最新数据。
2.3)数据结构
ZooKeeper 数据模型的结构与Unix 文件系统很类似,整体上可以看作是一棵树,每个节点称做一个ZNode。每一个ZNode 默认能够存储1MB 的数据(不能存储海量数据),每个ZNode 都可以通过其路径唯一标识。
2.4)应用场景
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。
- 统一命名服务
- 在分布式环境下,经常需要对应用/服务进行统一命名,便于识别。例如:IP不容易记住,而域名容易记住。
- 统一配置管理
分布式环境下,配置文件同步非常常见。
(1)一般要求一个集群中,所有节点的配置信息是一致的,比如Kafka 集群。
(2)对配置文件修改后,希望能够快速同步到各个节点上。
配置管理可交由ZooKeeper实现。
(1)可将配置信息写入ZooKeeper上的一个Znode。
(2)各个客户端服务器监听这个Znode。
(3)一旦Znode中的数据被修改,ZooKeeper将通知各个客户端服务器。
- 统一集群管理
分布式环境中,实时掌握每个节点的状态是必要的。
(1)可根据节点实时状态做出一些调整。
ZooKeeper可以实现实时监控节点状态变化
(1)可将节点信息写入ZooKeeper上的一个ZNode。
(2)监听这个ZNode可获取它的实时状态变化。
- 服务器动态上下线
- 客户端能实时洞察到服务器上下线的变化
- 软负载均衡
- 在Zookeeper中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请求
3)ZooKeeper 命令操作
3.1)Zookeeper命令操作数据模型
•ZooKeeper 是一个树形目录服务,其数据模型和Unix的文件系统目录树很类似,拥有一个层次化结构。
•这里面的每一个节点都被称为: ZNode,每个节点上都会保存自己的数据和节点信息。
• 节点可以拥有子节点,同时也允许少量(1MB)数据存储在该节点之下。
•节点可以分为四大类:
•PERSISTENT 持久化节点
•EPHEMERAL 临时节点 :-e
•PERSISTENT_SEQUENTIAL 持久化顺序节点 :-s
•EPHEMERAL_SEQUENTIAL 临时顺序节点 :-es
3.2)Zookeeper命令操作服务端命令
•启动 ZooKeeper 服务: ./zkServer.sh start
•查看 ZooKeeper 服务状态: ./zkServer.sh status
•停止 ZooKeeper 服务: ./zkServer.sh stop
•重启 ZooKeeper 服务: ./zkServer.sh restart
3.3)Zookeeper客户端常用命令
•连接ZooKeeper服务端
1 | ./zkCli.sh –server ip:port |
•断开连接
1 | quit |
•查看命令帮助
1 | help |
•显示指定目录下节点
1 | ls 目录 |
•创建节点
1 | create /节点path value |
•获取节点值
1 | get /节点path |
•设置节点值
1 | set /节点path value |
•删除单个节点
1 | delete /节点path |
•删除带有子节点的节点
1 | deleteall /节点path |
3.4)客户端命令-创建临时有序节点
•创建临时节点
1 | create -e /节点path value |
•创建顺序节点
1 | create -s /节点path value |
•查询节点详细信息
1 | ls –s /节点path |
•czxid:节点被创建的事务ID
•ctime: 创建时间
•mzxid: 最后一次被更新的事务ID
•mtime: 修改时间
•pzxid:子节点列表最后一次被更新的事务ID
•cversion:子节点的版本号
•dataversion:数据版本号
•aclversion:权限版本号
•ephemeralOwner:用于临时节点,代表临时节点的事务ID,如果为持久节点则为0
•dataLength:节点存储的数据的长度
•numChildren:当前节点的子节点个数
3.5)监听器原理
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、节点删除、子目录节点增加删除)时,ZooKeeper 会通知客户端。监听机制保证ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序。
1、监听原理详解
- 首先要有一个main()线程
- 在main线程中创建Zookeeper客户端,这时就会创建两个线程,一个负责网络连接通信(connet),一个负责监听(listener)。
- 通过connect线程将注册的监听事件发送给Zookeeper。
- 在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
- Zookeeper监听到有数据或路径变化,就会将这个消息发送给listener线程。
- listener线程内部调用了process()方法。
2、常见的监听
1)监听节点数据的变化
1 | get path [watch] |
2)监听子节点增减的变化
1 | ls path [watch] |
4)ZooKeeper JavaAPI 操作
4.1)Curator介绍
•Curator 是 Apache ZooKeeper 的Java客户端库。
•常见的ZooKeeper Java API :
•原生Java API
•ZkClient
•Curator
•Curator 项目的目标是简化 ZooKeeper 客户端的使用。
•Curator 最初是 Netfix 研发的,后来捐献了 Apache 基金会,目前是 Apache 的顶级项目。
•官网:http://curator.apache.org/
4.2)JavaAPI操作建立连接
1,搭建项目
创建项目curator-zk
引入pom和日志文件
资料文件夹下pom.xml和log4j.properties
2、创建测试类,使用curator连接zookeeper
1 |
|
4.3)Zookeeper JavaAPI操作-创建节点
1 | /** |
1 |
|
4.4)ZookeeperJavaAPI操作-查询节点
1 | /** |
1 |
|
4.5)Zookeeper JavaAPI操作-修改节点
1 | /** |
1 |
|
4.6)Zookeeper JavaAPI操作-删除节点
1 | /** |
1 |
|
4.7)Zookeeper JavaAPI操作-Watch监听概述
•ZooKeeper 允许用户在指定节点上注册一些Watcher,并且在一些特定事件触发的时候,ZooKeeper 服务端会将事件通知到感兴趣的客户端上去,该机制是 ZooKeeper 实现分布式协调服务的重要特性。
•ZooKeeper 中引入了Watcher机制来实现了发布/订阅功能能,能够让多个订阅者同时监听某一个对象,当一个对象自身状态变化时,会通知所有订阅者。
•ZooKeeper 原生支持通过注册Watcher来进行事件监听,但是其使用并不是特别方便需要开发人员自己反复注册Watcher,比较繁琐。我们用Curator
•Curator引入了 Cache 来实现对 ZooKeeper 服务端事件的监听。
•ZooKeeper提供了三种Watcher:
•NodeCache : 只是监听某一个特定的节点
•PathChildrenCache : 监控一个ZNode的子节点.
•TreeCache : 可以监控整个树上的所有节点,类似于PathChildrenCache和NodeCache的组合
4.8Zookeeper JavaAPI操作-Watch监听-NodeCache
1 | /** |
4.9)Zookeeper JavaAPI操作-Watch监听-PathChildrenCache
1 |
|
4.10)Zookeeper JavaAPI操作-Watch监听-TreeCache
1 | /** |
4.11)Zookeeper分布式锁-概念
•在我们进行单机应用开发,涉及并发同步的时候,我们往往采用synchronized或者Lock的方式来解决多线程间的代码同步问题,这时多线程的运行都是在同一个JVM之下,没有任何问题。
•但当我们的应用是分布式集群工作的情况下,属于多JVM下的工作环境,跨JVM之间已经无法通过多线程的锁解决同步问题。
•那么就需要一种更加高级的锁机制,来处理种跨机器的进程之间的数据同步问题——这就是分布式锁。
4.12)Zookeeper 分布式锁-zookeeper分布式锁原理
•核心思想:当客户端要获取锁,则创建节点,使用完锁,则删除该节点。
1.客户端获取锁时,在lock节点下创建临时顺序节点。
2.然后获取lock下面的所有子节点,客户端获取到所有的子节点之后,如果发现自己创建的子节点序号最小,那么就认为该客户端获取到了锁。使用完锁后,将该节点删除。
3.如果发现自己创建的节点并非lock所有子节点中最小的,说明自己还没有获取到锁,此时客户端需要找到比自己小的那个节点,同时对其注册事件监听器,监听删除事件。
4.如果发现比自己小的那个节点被删除,则客户端的Watcher会收到相应通知,此时再次判断自己创建的节点是否是lock子节点中序号最小的,如果是则获取到了锁,如果不是则重复以上步骤继续获取到比自己小的一个节点并注册监听。
4.13)Zookeeper 分布式锁-模拟12306售票案例
Curator实现分布式锁API
在Curator中有五种锁方案:
InterProcessSemaphoreMutex:分布式排它锁(非可重入锁)
InterProcessMutex:分布式可重入排它锁
InterProcessReadWriteLock:分布式读写锁
InterProcessMultiLock:将多个锁作为单个实体管理的容器
InterProcessSemaphoreV2:共享信号量
1,创建线程进行加锁设置
1 | public class Ticket12306 implements Runnable{ |
2,创建连接,并且初始化锁
1 | public Ticket12306(){ |
3,运行多个线程进行测试
1 | public class LockTest { |
5)ZooKeeper 集群搭建
5.1)Zookeeper集群选举机制
SID: 服务器ID。用来唯一标识一台ZooKeeper集群中的机器,每台机器不能重复,和myid一致。
ZXID: 事务ID。ZXID是一个事务ID,用来标识一次服务器状态的变更。在某一时刻,集群中的每台机器的ZXID值不一定完全一致,这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。
Epoch: 每个Leader任期的代号。没有Leader时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加。
Zookeeper选举机制——第一次启动
(1)服务器1启动,发起一次选举。服务器1投自己一票。此时服务器1票数一票,不够半数以上(3票),选举无法完成,服务器1状态保持为LOOKING;
(2)服务器2启动,再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的myid比自己目前投票推举的(服务器1)大,更改选票为推举服务器2。此时服务器1票数0票,服务器2票数2票,没有半数以上结果,选举无法完成,服务器1,2状态保持LOOKING。
(3)服务器3启动,发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果:服务器1为0票,服务器2为0票,服务器3为3票。此时服务器3的票数已经超过半数,服务器3当选Leader。服务器1,2更改状态为FOLLOWING,服务器3更改状态为LEADING;
(4)服务器4启动,发起一次选举。此时服务器1,2,3已经不是LOOKING状态,不会更改选票信息。交换选票信息结果:服务器3为3票,服务器4为1票。此时服务器4服从多数,更改选票信息为服务器3,并更改状态为FOLLOWING;
(5)服务器5启动,同4一样当小弟。
Zookeeper选举机制——非第一次启动
(1)当ZooKeeper集群中的一台服务器出现以下两种情况之一时,就会开始进入Leader选举:
- 服务器初始化启动。
- 服务器运行期间无法和Leader保持连接。
(2)而当一台机器进入Leader选举流程时,当前集群也可能会处于以下两种状态:
集群中本来就已经存在一个Leader。
对于第一种已经存在Leader的情况,机器试图去选举Leader时,会被告知当前服务器的Leader信息,对于该机器来说,仅仅需要和Leader机器建立连接,并进行状态同步即可。
集群中确实不存在Leader。
假设ZooKeeper由5台服务器组成,SID分别为1、2、3、4、5,ZXID分别为8、8、8、7、7,并且此时SID为3的服务器是Leader。某一时刻,3和5服务器出现故障,因此开始进行Leader选举。
选举Leader规则:
①EPOCH大的直接胜出
②EPOCH相同,事务id大的胜出
③事务id相同,服务器id大的胜出
5.2)搭建要求
真实的集群是需要部署在不同的服务器上的,但是在我们测试时同时启动很多个虚拟机内存会吃不消,所以我们通常会搭建伪集群,也就是把所有的服务都搭建在一台虚拟机上,用端口进行区分。
我们这里要求搭建一个三个节点的Zookeeper集群(伪集群)。
5.3)准备工作
重新部署一台虚拟机作为我们搭建集群的测试服务器。
(1)安装JDK 【此步骤省略】。
(2)Zookeeper压缩包上传到服务器
(3)将Zookeeper解压 ,建立/usr/local/zookeeper-cluster目录,将解压后的Zookeeper复制到以下三个目录
/usr/local/zookeeper-cluster/zookeeper-1
/usr/local/zookeeper-cluster/zookeeper-2
/usr/local/zookeeper-cluster/zookeeper-3
1 | [root@localhost ~]# mkdir /usr/local/zookeeper-cluster |
(4)创建data目录 ,并且将 conf下zoo_sample.cfg 文件改名为 zoo.cfg
1 | mkdir /usr/local/zookeeper-cluster/zookeeper-1/data |
(5) 配置每一个Zookeeper 的dataDir 和 clientPort 分别为2181 2182 2183
修改/usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg
1 | vim /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg |
修改/usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg
1 | vim /usr/local/zookeeper-cluster/zookeeper-2/conf/zoo.cfg |
修改/usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg
1 | vim /usr/local/zookeeper-cluster/zookeeper-3/conf/zoo.cfg |
5.4)配置集群
(1)在每个zookeeper的 data 目录下创建一个 myid 文件,内容分别是1、2、3 。这个文件就是记录每个服务器的ID
1 | echo 1 >/usr/local/zookeeper-cluster/zookeeper-1/data/myid |
(2)在每一个zookeeper 的 zoo.cfg配置客户端访问端口(clientPort)和集群服务器IP列表。
集群服务器IP列表如下
1 | vim /usr/local/zookeeper-cluster/zookeeper-1/conf/zoo.cfg |
解释:server.服务器ID=服务器IP地址:服务器之间通信端口:服务器之间投票选举端口
5.5)启动集群
启动集群就是分别启动每个实例。
1 | /usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh start |
启动后我们查询一下每个实例的运行状态
1 | /usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh status |
先查询第一个服务
Mode为follower表示是跟随者(从)
再查询第二个服务Mod 为leader表示是领导者(主)
查询第三个为跟随者(从)
5.6)模拟集群异常
(1)首先我们先测试如果是从服务器挂掉,会怎么样
把3号服务器停掉,观察1号和2号,发现状态并没有变化
1 | /usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh stop |
由此得出结论,3个节点的集群,从服务器挂掉,集群正常
(2)我们再把1号服务器(从服务器)也停掉,查看2号(主服务器)的状态,发现已经停止运行了。
1 | /usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh stop |
由此得出结论,3个节点的集群,2个从服务器都挂掉,主服务器也无法运行。因为可运行的机器没有超过集群总数量的半数。
(3)我们再次把1号服务器启动起来,发现2号服务器又开始正常工作了。而且依然是领导者。
1 | /usr/local/zookeeper-cluster/zookeeper-1/bin/zkServer.sh start |
(4)我们把3号服务器也启动起来,把2号服务器停掉,停掉后观察1号和3号的状态。
1 | /usr/local/zookeeper-cluster/zookeeper-3/bin/zkServer.sh start |
发现新的leader产生了~
由此我们得出结论,当集群中的主服务器挂了,集群中的其他服务器会自动进行选举状态,然后产生新得leader
(5)我们再次测试,当我们把2号服务器重新启动起来启动后,会发生什么?2号服务器会再次成为新的领导吗?我们看结果
1 | /usr/local/zookeeper-cluster/zookeeper-2/bin/zkServer.sh start |
我们会发现,2号服务器启动后依然是跟随者(从服务器),3号服务器依然是领导者(主服务器),没有撼动3号服务器的领导地位。
由此我们得出结论,当领导者产生后,再次有新服务器加入集群,不会影响到现任领导者。
xxx
6)Zookeeper 核心理论
Zookeepe集群角色
在ZooKeeper集群服中务中有三个角色:
•Leader 领导者 :
1. 处理事务请求
2. 集群内部各服务器的调度者
•Follower 跟随者 :
1. 处理客户端非事务请求,转发事务请求给Leader服务器
2. 参与Leader选举投票
•Observer 观察者:
- 处理客户端非事务请求,转发事务请求给Leader服务器