1.Zookeeper的概述
Zookeeper 是一个开源的分布式协调服务框架 ,主要用来解决分布式集群中应用系统的一致性问题和数据管理问题
Zookeeper 本质上是一个分布式文件系统, 适合存放小文件,也可以理解为一个数据库
2.Zookeeper的特点
-
Zookeeper 中存储的其实是一个又一个 Znode, Znode 是 Zookeeper 中的节点
-
Znode 是有路径的, 例如
/data/host1
,/data/host2
, 这个路径也可以理解为是 Znode 的 Name -
Znode 也可以携带数据, 例如说某个 Znode 的路径是
/data/host1
, 其值是一个字符串"192.168.0.1"
-
-
正因为 Znode 的特性, 所以 Zookeeper 可以对外提供出一个类似于文件系统的试图, 可以通过操作文件系统的方式操作 Zookeeper
-
使用路径获取 Znode
-
获取 Znode 携带的数据
-
修改 Znode 携带的数据
-
删除 Znode
-
添加 Znode
-
3.Zookeeper的应用场景
3.1:数据的发布与订阅
数据发布/订阅系统,需要发布者将数据发布到Zookeeper的节点上,供订阅者进行数据订阅,进而达到动态获取数据的目的,实现配置信息的集中式管理和数据的动态更新。
3.2:命名服务
命名服务是分步实现系统中较为常见的一类场景,分布式系统中,被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等,通过命名服务,客户端可以根据指定名字来获取资源的实体,在分布式环境中,上层应用仅仅需要一个全局唯一的名字。Zookeeper可以实现一套分布式全局唯一ID的分配机制。
3.3心跳检测
不同机器间需要检测到彼此是否在正常运行,可以使用Zookeeper实现机器间的心跳检测,基于其临时节点特性(临时节点的生存周期是客户端会话,客户端若当即后,其临时节点自然不再存在),可以让不同机器都在Zookeeper的一个指定节点下创建临时子节点,不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活。通过Zookeeper可以大大减少系统耦合。
3.4工作进度汇报
通常任务被分发到不同机器后,需要实时地将自己的任务执行进度汇报给分发系统,可以在Zookeeper上选择一个节点,每个任务客户端都在这个节点下面创建临时子节点,这样不仅可以判断机器是否存活,同时各个机器可以将自己的任务执行进度写到该临时节点中去,以便中心系统能够实时获取任务的执行进度。
3.5系统调度
Zookeeper能够实现如下系统调度模式:分布式系统由控制台和一些客户端系统两部分构成,控制台的职责就是需要将一些指令信息发送给所有的客户端,以控制他们进行相应的业务逻辑,后台管理人员在控制台上做一些操作,实际上就是修改Zookeeper上某些节点的数据,Zookeeper可以把数据变更以时间通知的形式发送给订阅客户端。
3.6分布式锁
分布式锁用于控制分布式系统之间同步访问共享资源的一种方式,可以保证不同系统访问一个或一组资源时的一致性,主要分为排它锁和共享锁。
排它锁又称为写锁或独占锁,若事务T1对数据对象O1加上了排它锁,那么在整个加锁期间,只允许事务T1对O1进行读取和更新操作,其他任何事务都不能再对这个数据对象进行任何类型的操作,直到T1释放了排它锁。
共享锁又称为读锁, 若事务T1对数据对象O1加上共享锁,那么当前事务只能对O1进行读取操作,其他事务也只能对这个数据对象加共享锁,直到该数据对象上的所有共享锁都被释放。在需要获取共享锁时,所有客户端都会到/shared_lock下面创建一个临时顺序节点
① 获取锁,在需要获取排它锁时,所有客户端通过调用接口,在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功,没有成功的客户端需要注册/exclusive_lock节点监听。
② 释放锁,当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除,此时,所有在/exclusive_lock节点上注册监听的客户端都会收到通知,可以重新发起分布式锁获取。
3.7分布式队列
分为3种角色:
-
Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader,它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
-
Follower 一个Zookeeper集群可能同时存在多个Follower,它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求,同时会将写请求转发给Leader处理,并且负责在Leader处理写请求时对请求进行投票。
-
Observer 角色与Follower类似,但是无投票权。
4.Zookeeper的选举机制
每个Server发出一个投票。由于是初始情况,Server1和Server2都会将自己作为Leader服务器来进行投票,每次投票会包含所推举的服务器的myid和ZXID,使用(myid, ZXID)来表示,此时Server1的投票为(1, 0),Server2的投票为(2, 0),然后各自将这个投票发给集群中其他机器。
处理投票。针对每一个投票,服务器都需要将别人的投票和自己的投票进行PK,PK规则如下
· 优先检查ZXID。ZXID比较大的服务器优先作为Leader。
· 如果ZXID相同,那么就比较myid。myid较大的服务器作为Leader服务器
5.Zookeeper的Shell 客户端操作
1:创建普通节点
create /app1 hello
2: 创建顺序节点
create -s /app3 world
3:创建临时节点
create -e /tempnode world
4:创建顺序的临时节点
create -s -e /tempnode2 aaa
5:获取节点数据
get /app1
6:修改节点数据
set /app1 xxx
7:删除节点
delete /app1 删除的节点不能有子节点
rmr /app1 递归删除
6.Zookeeper的JavaAPI操作
1.创建maven工程导入Zookeeper 的pom文件
2.创建节点
注:这套流程基本上所有的操作都要用
1.定制重试策略:
param1 :重试间隔时间
param2:重试最大次数
RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,1);
2. 获取客户端对象
param1:要连接的Zookeeper服务器列表
param2:会话超时时间
param3:连接超时时间
param4:重试策略
CuratorFramework client =CuratorFrameworkFactory.newClient(“String”,int,int,“String”)
3.开启客户端
client.start();
4.创建节点
client.create().creatingParentsIfNeeded().withMode(CreateMode.PERSISTENT).forpath(“节点名称”,“数据”.getBytes())
withMode(CreateMode.PERSISTENT)创建永久节点
withMode(CreateMode.EPHEMERAL)创建临时节点
withMode(CreateMode.PERSISTENT_SEQUENTIAL)创建永久序列化节点
withMode(CreateMode.EPHEMERAL_SEQUENTIAL)创建临时序列化节点
5.关闭客户端
client.close
3.修改节点数据
client.setData().forpath(“节点名称”,“修改数据”.getBytes());
4.查询节点数据
获取节点数据
byte[]bytes = client.getData().forpath("节点名称")
5.节点的watch机制
创建TreeCache对象,指定要控制的节点路径
TreeCache treeCache =new TreeCache(client,“节点名称”)
自定以一个监听器
treeCache.getListenable().addListener(){}