2 Zookeeper_PhoenixLuo·

网络 02-07 3605

2.1 Zookeeper 的概述

2.2 Zookeeper的特点

2.3 Zookeeper的架构

2.4 Zookeeper的应用场景

2.4.1 数据发布/订阅

2.4.2 命名服务

2.4.3 分布式协调/通知

2.4.4 分布式锁

2.4.5 分布式队列

2.5 Zookeeper的选举机制

2.5.1. 服务器启动时期的Leader选举

3.5.2.服务器运行时期的Leader选举

2.6 Zookeeper安装

2.7 Zookeeper的Shell 客户端操作

2.7.1 节点属性

2.7.2 zookeeper的watch机制

2.7.3 zookeeper的JavaApi操作

创建Java工程，导入jar包

创建临时节点

2.1 Zookeeper 的概述

Zookeeper 是一个开源的分布式协调服务框架，主要用来解决分布式集群中应用系统的一致性问题和数据管理问题

2.2 Zookeeper的特点

Zookeeper 本质上是一个分布式文件系统, 适合存放小文件，也可以理解为一个数据库

在上图左侧, Zookeeper 中存储的其实是一个又一个 Znode, Znode 是 Zookeeper 中的节点

Znode 是有路径的, 例如 /servers/host1 , /servers/host2 , 这个路径也可以理解为是 Znode 的 NameZnode 也可以携带数据, 例如说某个 Znode 的路径是 /servers/host1 , 其值是一个字符串 "192.168.0.1"

正因为 Znode 的特性, 所以 Zookeeper 可以对外提供出一个类似于文件系统的视图, 可以通过操作文件系统的方式操作 Zookeeper

使用路径获取 Znode获取 Znode 携带的数据修改 Znode 携带的数据删除 Znode 添加 Znode

2.3 Zookeeper的架构

Zookeeper集群是一个基于主从架构的高可用集群

每个服务器承担如下三种角色中的一种

Leader 一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各 Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。

Follower 一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票。

Observer 角色与Follower类似，但是无投票权。

2.4 Zookeeper的应用场景 2.4.1 数据发布/订阅

数据发布/订阅系统,需要发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。

发布/订阅一般有两种设计模式：推模式和拉模式，服务端主动将数据更新发送给所有订阅的客户端称为推模式；客户端主动请求获取最新数据称为拉模式.

Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。

2.4.2 命名服务

命名服务是分步实现系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实体，在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper 可以实现一套分布式全局唯一ID的分配机制。

通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点，并且在API返回值中会返回这个节点的完整名字，利用此特性，可以生成全局ID，其步骤如下

客户端根据任务类型，在指定类型的任务下通过调用接口创建一个顺序节点，如"job-"。创建完成后，会返回一个完整的节点名，如"job-00000001"。客户端拼接type类型和返回值后，就可以作为全局唯一ID了，如"type2-job-00000001"。

2.4.3 分布式协调/通知

Zookeeper中特有的Watcher注册于异步通知机制，能够很好地实现分布式环境下不同机器，甚至不同系统之间的协调与通知，从而实现对数据变更的实时处理。

通常的做法是不同的客户端都对Zookeeper上的同一个数据节点进行Watcher注册，监听数据节点的变化（包括节点本身和子节点），若数据节点发生变化，那么所有订阅的客户端都能够接收到相应的 Watcher通知，并作出相应处理。

在绝大多数分布式系统中，系统机器间的通信无外乎心跳检测、工作进度汇报和系统调度。

① 心跳检测，不同机器间需要检测到彼此是否在正常运行，可以使用Zookeeper实现机器间的心跳检测，基于其临时节点特性（临时节点的生存周期是客户端会话，客户端若当即后，其临时节点自然不再存在），可以让不同机器都在Zookeeper的一个指定节点下创建临时子节点，不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活。通过 Zookeeper可以大大减少系统耦合。

② 工作进度汇报，通常任务被分发到不同机器后，需要实时地将自己的任务执行进度汇报给分发系统，可以在Zookeeper上选择一个节点，每个任务客户端都在这个节点下面创建临时子节点，这样不仅可以判断机器是否存活，同时各个机器可以将自己的任务执行进度写到该临时节点中去，以便中心系统能够实时获取任务的执行进度。

③ 系统调度，Zookeeper能够实现如下系统调度模式：分布式系统由控制台和一些客户端系统两部分构成，控制台的职责就是需要将一些指令信息发送给所有的客户端，以控制他们进行相应的业务逻辑，后台管理人员在控制台上做一些操作，实际上就是修改Zookeeper上某些节点的数据，Zookeeper可以把数据变更以时间通知的形式发送给订阅客户端。

2.4.4 分布式锁

分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，可以保证不同系统访问一个或一组资源时的一致性，主要分为排它锁和共享锁。

排它锁又称为写锁或独占锁，若事务T1对数据对象O1加上了排它锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任何类型的操作，直到T1释放了排它锁。

① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成功的客户端需要注册/exclusive_lock节点监听。

② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。

共享锁又称为读锁，若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。在需要获取共享锁时，所有客户端都会到/shared_lock下面创建一个临时顺序节点

2.4.5 分布式队列

有一些时候，多个团队需要共同完成一个任务，比如，A团队将Hadoop集群计算的结果交给B团队继续计算，B完成了自己任务再交给C团队继续做。这就有点像业务系统的工作流一样，一环一环地传下去. 分布式环境下，我们同样需要一个类似单进程队列的组件，用来实现跨进程、跨主机、跨网络的数据共享和数据传递，这就是我们的分布式队列。

2.5 Zookeeper的选举机制

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

一般选取奇数个机子

2.5.1. 服务器启动时期的Leader选举

若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

(1) 每个Server发出一个投票。由于是初始情况，Server1和Server2都会将自己作为 Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用(myid, ZXID) 来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

(2) 接受来自各个服务器的投票。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

(3) 处理投票。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK 规则如下

优先检查ZXID。ZXID比较大的服务器优先作为Leader。前提是票数要过半如果ZXID相同，那么就比较myid。myid较大的服务器作为Leader服务器。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的 ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

(4) 统计投票。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

(5) 改变服务器状态。一旦确定了Leader，每个服务器就会更新自己的状态，如果是 Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

3.5.2.服务器运行时期的Leader选举

在Zookeeper运行期间，Leader与非Leader服务器各司其职，即便当有非Leader服务器宕机或新加入，此时也不会影响Leader，但是一旦Leader服务器挂了，那么整个集群将暂停对外服务，进入新一轮Leader选举，其过程和启动时期的Leader选举过程基本一致过程相同。

2.6 Zookeeper安装

集群规划

服务器IP

主机名

myid的值（相当于集群中每一个zookeeper服务器的一个编号）

192.168.245.100

node01

192.168.245.110

node02

192.168.245.120

node03

第一步：下载zookeeeper的压缩包，下载网址如下

Index of /dist/zookeeper

我们在这个网址下载我们使用的zk版本为3.4.9

下载完成之后，上传到我们的linux的/export/softwares 路径下准备进行安装

输入命令rz -E 进行上传

移动到/export/softwares 路径下 mv zookeeper-3.4.9.tar.gz /export/softwares/

第二步：解压

解压zookeeper的压缩包到/export/servers路径下去，然后准备进行安装

cd /export/software

tar -zxvf zookeeper-3.4.9.tar.gz -C ../servers/

第三步：修改配置文件

第一台机器修改配置文件

cd /export/servers/zookeeper-3.4.9/conf/

cp zoo_sample.cfg zoo.cfg

mkdir -p /export/servers/zookeeper-3.4.9/zkdatas/ （此行命令用于第四步）

vim zoo.cfg

dataDir=/export/servers/zookeeper-3.4.9/zkdatas # 保留多少个快照 autopurge.snapRetainCount=3 # 日志多少小时清理一次 autopurge.purgeInterval=1 # 集群中服务器地址 server.1=node01:2888:3888 server.2=node02:2888:3888 server.3=node03:2888:3888

（去掉注释即可）

（在最后加上这三行命令）

第四步：添加myid配置

在第一台机器的 /export/servers/zookeeper-3.4.9/zkdatas /这个路径下创建一个文件，文件名为myid ,文件内容为1

输入命令vim myid，手动添加内容为1

第五步：安装包分发并修改myid的值

安装包分发到其他机器

第一台机器上面执行以下两个命令（在/export/servers/目录下进行）

scp -r /export/servers/zookeeper-3.4.9/ node02:/export/servers/

scp -r /export/servers/zookeeper-3.4.9/ node03:/export/servers/

-------------------------------------------------

（node02查看）

-------------------------------------------------

(node03查看）

-------------------------------------------------

第六步：三台机器启动zookeeper服务

三台机器启动zookeeper服务，这个命令三台机器都要执行 /export/servers/zookeeper-3.4.9/bin/zkServer.sh start

查看启动状态 /export/servers/zookeeper-3.4.9/bin/zkServer.sh status

2.7 Zookeeper的Shell 客户端操作

bin/zkCli.sh -server node01:2181

当我第一次输入启动zookeeper命令时，一直出现reconnect，后来我把另外两台node02和03打开后，就没事了。

操作实例

1、列出Path下的所有Znode ls /

2、创建永久节点 create /hello world

3、创建临时结点 create -e /tmp world

当会话结束，再进入时，之前创建的临时结点没有了

4、创建永久序列化结点 create -s /hello2 world

5、创建临时序列化结点 create -s -e /tmp world

结点既有文件特性也有目录特性，以上是具有文件特性，因为存储了文件，以下是目录特性

6、修改节点数据 set /hello zookeeper

7、删除结点，如果要删除的结点有子Znode则无法删除 delete /hello

8、删除结点，如果有子Zode则递归删除 rmr /abc

9、列出历史 history

2.7.1 节点属性

每个Znode都包含了一系列属性，通过命令get，可以获得结点的属性

cZxid = Znode创建的事务id

ctime = 结点创建时的时间戳

mZxid = znode被修改的事务id，即每次对znode的修改都会更新mZxid，看这个id越大，说明越后发生

mtime = 结点最后一次更新发生时的时间戳

pZxid = 0x30000000c

cversion = 子节点的版本号。当znode的子节点有点变化时，cversion的值就会增加1

dataVersion = 数据版本号，每次对结点进行set操作，dataVersion的值就会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。

aclVersion = ACL的版本号

ephemeralOwner = 如果改结点为临时节点，这个值表示与该结点绑定的session id，如果不是则值为0

dataLength = 5

numChildren = 1

2.7.2 zookeeper的watch机制

· 通知类似于数据库中的触发器，对某个Znode设置的watcher，当Znode发生变化的时候，watchmanager会调用对应的watcher

· 当Znode发生删除，修改，创建，子节点修改的时候，对应的watcher会得到通知

· watcher的特点

· 一次性触发一个watcher只会被触发一次，如果需要继续监听则需要再次添加watcher

· 事件封装：watcher得到的事件是被封装的，包括三个内容 keeperState，eventType，path

打开192.168.245.100 设置一个watch机制

再复制一个窗口，对hello进行设置，

之后再返回第一个打开的窗口，就可以看到监听到的更新状态

2.7.3 zookeeper的JavaApi操作

这里操作zookeeper的JavaApi使用的是一套zookeeper客户端框架Curator，解决了很多zookeeper客户端非常底层的细节开发工作

Curator包含了几个包：

· curator-framework：对zookeeper的底层api的一些封装

· curator-recipes：封装了一些高级特性，如Cache事件监听、选举、分布式锁、分布式计数器等

Maven依赖（使用curator版本：2.12.0，对应zookeeper的版本为：3.4.x，如果跨版本会有兼容性问题，很有可能导致节点操作失败）：

创建Java工程，导入jar包

1、建立一个project

2、File-new-module-Maven

3、直接点next

4、建立依赖仓库

<dependencies> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-framework</artifactId> <version>2.12.0</version> </dependency> <dependency> <groupId>org.apache.curator</groupId> <artifactId>curator-recipes</artifactId> <version>2.12.0</version> </dependency> <dependency> <groupId>com.google.collections</groupId> <artifactId>google-collections</artifactId> <version>1.0</version> </dependency> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>RELEASE</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-simple</artifactId> <version>1.7.25</version> </dependency> </dependencies> <build> <plugins> <pulgin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.2</version> <configuration> <source>1.8</source> <target>1.8</target> <encoding>UTF-8</encoding> </configuration> </pulgin> </plugins> </build>

?创建永久结点

@Test public void createNode() throws Exception{ RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,1); //获取客户端对象 CuratorFramework client = CuratorFrameworkFactory.newClient("192.168.245.100:2181,192.168.245.110:2181,192.168.245.120:2181",1000,1000,retryPolicy); //调用start开启客户端操作 client.start(); //通过create来进行创建结点，并且需要指定节点类型 client.create().creatingParentsIfNeeded().withMode(CreateMode.PERSISTENT).forPath("/hello3/world"); client.close(); }

在这个包里创建这个类

代码如下：

package cn.itcast.zookeeper_api; import org.apache.curator.RetryPolicy; import org.apache.curator.framework.CuratorFramework; import org.apache.curator.framework.CuratorFrameworkFactory; import org.apache.curator.retry.ExponentialBackoffRetry; import org.apache.zookeeper.CreateMode; import org.junit.Test; public class zookeeperApiTest { @Test public void createZnode(){ //1:定制一个重试策略 RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,1); //2:获取一个客户端对象 /* param1:要连接的zookeeper服务器列表 param2：会话的超时时间 param3:链接超时时间 param4:重试策略 */ String connectionStr="192.168.245.100:2181,192.168.245.110:2181,192.168.245.120:2181"; CuratorFramework client = CuratorFrameworkFactory.newClient(connectionStr,8000,8000,retryPolicy); //3:开启客户端 client.start(); //4:创建结点 client.create().creatingParentsIfNeeded().withMode(CreateMode.PERSISTENT).forPath("/hello2","world".getBytes()); //5:关闭客户端 client.close(); } }

创建临时节点 @Test /*创建临时节点*/ public void createTmpZnode() throws Exception { //1:定制一个重试策略 RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,1); //2:获取一个客户端对象 /* param1:要连接的zookeeper服务器列表 param2：会话的超时时间 param3:链接超时时间 param4:重试策略 */ String connectionStr="192.168.245.100:2181,192.168.245.110:2181,192.168.245.120:2181"; CuratorFramework client = CuratorFrameworkFactory.newClient(connectionStr,8000,8000,retryPolicy); //3:开启客户端 client.start(); //4:创建结点 client.create().creatingParentsIfNeeded().withMode(CreateMode.EPHEMERAL ).forPath("/hello4","world".getBytes()); //5:关闭客户端 client.close(); }

修改数据

@Test public void setZnodeData() throws Exception { RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,1); String connectionStr="192.168.245.100:2181,192.168.245.110:2181,192.168.245.120:2181"; CuratorFramework client = CuratorFrameworkFactory.newClient(connectionStr,8000,8000,retryPolicy); client.start(); client.setData().forPath("/hello","zookeeper".getBytes()); client.close(); }

修改前为：

修改后为：

获取节点数据

/*获取节点数据*/ @Test public void getZnodeData() throws Exception { RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000,1); String connectionStr="192.168.245.100:2181,192.168.245.110:2181,192.168.245.120:2181"; CuratorFramework client = CuratorFrameworkFactory.newClient(connectionStr,8000,8000,retryPolicy); client.start(); byte[] bytes = client.getData().forPath("/hello"); System.out.println(new String(bytes)); client.close(); }

节点的watch机制?

/*节点的watch机制*/ @Test public void watchZnode() throws Exception { RetryPolicy retryPolicy = new ExponentialBackoffRetry(3000,1); String connectionStr="192.168.245.100:2181,192.168.245.110:2181,192.168.245.120:2181"; CuratorFramework client = CuratorFrameworkFactory.newClient(connectionStr,8000,8000,retryPolicy); client.start(); TreeCache treeCache = new TreeCache(client,"/hello5"); treeCache.getListenable().addListener((new TreeCacheListener() { @Override public void childEvent(CuratorFramework curatorFramework, TreeCacheEvent treeCacheEvent) throws Exception { ChildData data = treeCacheEvent.getData(); if(data!=null){ switch (treeCacheEvent.getType()){ case NODE_ADDED: System.out.println("监控到有新增节点"); break; case NODE_REMOVED: System.out.println("监控到有节点被移除"); break; case NODE_UPDATED: System.out.println("监控到有节点被更新"); break; default: break; } } } })); treeCache.start(); Thread.sleep(1000000); }