第七章：Zookeeper
第1节：介绍
1.1 概述
1.介绍
Zookeeper是一个开源的分布式的，分布式应用程序协调服务软件。为分布式应用提供协调服务的Apache项目。提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
2.工作机制
基于观察者模式设计的分布式服务管理框架。
3. ZooKeeper的基本运转流程：
1、选举Leader。
2、同步数据。
3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。
4、Leader要具有最高的执行ID，类似root权限。
5、集群中大多数的机器得到响应并接受选出的Leader。
1.2 特点
Zookeeper官方架构图
奇数：集群都搭建奇数台。
1.Zookeeper：一个领导级别的存在，监测和管理多个服务。
2.集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
3.数据一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
4.更新请求顺序进行：来自同一个Client的更新请求按照其发送顺序依次执行。
5.原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
6.实时性：在一定时间范围，Client能读到最新的数据。
1.3 数据结构
Zookeeper数据模型的结构与linux文件系统很类似，都是树结构。树上有若干个节点，每个节点能够存储1MB的数据，同时每个节点都是通过其路径可以唯一标识的。
zk： 每个节点的路径都是唯一，确定。
1.4 企业应用场景（了解）
Zookeeper服务包括：统一命名服务、统一配置管理、统一集群管理、软负载均衡等。
1.统一命名服务
命名服务是分布式系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等。通过命名服务，客户端可以根据指定名字来获取资源的实体、服务地址和提供者信息。例如一般用户都是通过域名来访问应用而不是IP。阿里开源分布式服务框架Dubbo中使用zookeeper来作为其命名服务，维护全局的服务列表。
2.统一配置管理
（1）配置文件同步，集群中所有配置文件的信息都是一致的，对配置文件修改后，快速同步到各个节点上。
（2）Zookeeper实现配置管理。将配置信息写入到Zookeeper上的节点，然后各个客户端服务器监听这个节点，一但节点中的数据发生变化，Zookeeper将通知到各个客户端服务器。
3.统一集群管理
zookeeper的两大特性：节点特性和watcher机制
（1）分布式环境中实时掌握每个节点的状态，并根据节点实时状态做出一定的调整。
（2）在实时监测到节点变化后，将节点的信息写入到Zookeeper上的节点，通过监听该节点来获取它的实时状态变化。
4.负载均衡
zookeeperk实现负载均衡就是通过watcher机制和临时节点判断哪些节点宕机来获取可用的节点来实现的,
zookeeperk会维护一个树形的数据结构，类似于window的资源管理器目录，其中 EPHEMERAL(临时）节点会随着创建它的客户端端口而被删除，利用这个特性很容易实现软负载均衡。
第2节：安装与配置
2.1 下载安装
1、Zookeeper下载
下载地址：https://zookeeper.apache.org/releases.html#download
2．安装前准备
（1）安装Jdk
（2）拷贝Zookeeper安装包到Linux系统下： xftp
（3）解压到指定目录
tar -zxvf apache-zookeeper-3.4.10-bin.tar.gz -C /usr/local
3．配置修改
（1）将/usr/local/apache-zookeeper-3.4.10-bin/conf这个路径下的zoo_sample.cfg修改为zoo.cfg；
cp zoo_sample.cfg zoo.cfg
（2）打开zoo.cfg文件，修改dataDir路径：
vim zoo.cfg
修改如下内容：
dataDir=/usr/local/apache-zookeeper-3.4.10-bin/zkData
（3）在/usr/local/apache-zookeeper-3.4.10-bin这个目录上创建zkData文件夹
mkdir zkData
4．操作Zookeeper
（1）启动Zookeeper
在/usr/local/apache-zookeeper-3.4.10-bin目录下执行
bin/zkServer.sh start| status | stop | restart
zk的启动命令| 查询状态命名 | stop 停止命令 | 重启
（2）启动客户端：
在/usr/local/ujiuye/apache-zookeeper-3.4.10-bin目录下执行
bin/zkCli.sh
（3）quit退出客户端：
启动时如果出现问题，我们可以去查看zookeeperlogs目录中的日志文件。
如果时8080端口被占用（zookeeper管理程序在启动时需要占用8080端口），我们可以查看8080端口被哪个程序占用（netstat -tunlp | grep 8080）并停止
但如果8080被占用并且不能停止，我们可以去修改zookeeper管理程序所占用的端口
zoo.cfg文件中
admin.serverPort=9090
2.2 配置参数解读[了解]
Zookeeper中的配置文件zoo.cfg中参数含义解读如下
1．tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒
Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。
它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)
2．initLimit =10：LF（flower|leader）初始通信时限
集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。
3．syncLimit =5：LF同步通信时限
集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。
4．dataDir：数据文件目录+数据持久化路径
主要用于保存Zookeeper中的数据。
5．clientPort =2181：客户端连接端口
监听客户端连接的端口。
6. admin.serverPort=8080(默认)
2.3 znode内容
cZxid: 创建节点时的事务ID,
ctime: 创建节点时的时间
mZxid: 最后修改节点时的事务ID, 每次修改 znode 状态都会产生一个唯一的事务ID, 如果 zxid1 小于 zxid2, 则 zxid1 在 zxid2 之前发生
mtime: 最后修改节点时的时间
pZxid: 表示该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID（注意，只有子节点列表变更了才会变更 pzxid，子节点内容变更不会影响 pzxid）
cversion: 子节点版本号，子节点每次修改版本号加1
dataversion: 数据版本号，数据每次修改该版本号加1
aclversion: 权限版本号，权限每次修改该版本号加1
ephemeralOwner: 创建该临时节点的会话的sessionID。（如果该节点是持久节点，那么这个属性值为0）
dataLength: 该节点的数据长度
numChildren: 该节点拥有子节点的数量（只统计直接子节点的数量）
2.4 常见命令
1．启动客户端
bin /zkCli.sh
2．显示所有操作命令
help
3．查看当前znode中所包含的内容
ls /
4．分别创建2个普通持久节点：
create /shuihu "songjiang"
create /shuihu/liangshan "liubei"
6．获得节点的值
get /shuihu get -s /shuihu(显示详细信息)
7．创建短暂节点: 当客户端和服务器端断开链接的时候， 短暂节点消失
create -e /shuihu/liangshan "likui"
（1）在当前客户端是能查看到的
ls /shuihu
（2）退出当前客户端然后再重启客户端
quit:退出
bin/zkCli.sh重新进入
（3）再次查看根目录下短暂节点已经删除
ls /shuihu
8．创建带序号的节点
（1）先创建一个普通的根节点/shuihu/liangshan
create /shuihu/liangshan/daxia "yanqing"
Created /shuihu/liangshan/daxia
（2）创建带序号的节点
create -s /shuihu/laingshan/yishi "lujunyi"
如果原来没有序号节点，序号从0开始依次递增。如果原节点下已有2个节点，则再排序时从2开始，以此类推。
9．修改节点数据值
set /shuihu/liangshan "lishishi"
10．节点的值变化监听【了解】
（1）在hadoop104主机上注册监听/shuihu节点数据变化
get /shuhui watch
get -w
（2）在hadoop103主机上修改/shuihu节点的数据
set /shuihu "huangdi"
（3）观察hadoop104主机收到数据变化的监听
WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/shuihu
11．节点的子节点变化监听（路径变化）【了解】
（1）在hadoop104主机上注册监听/sanguo节点的子节点变化
ls /shuihu watch
（2）在hadoop103主机/liangshan节点上创建子节点
create /shuihu/chaoting "huarong"
（3）观察hadoop104主机收到子节点变化的监听
WATCHER::
WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/shuihu
注意： 单个节点使用get 检测：
多个层级节点，使用ls 检测
12．删除节点： 删除的节点下没有子节点
delete /shuihu/chaoting
delete -v 0 /shuihu/chaoting
13．递归删除节点
rmr /路径 （建议使用deleteall替代rmr）
14．查看节点状态
stat /shuihu
第3节：集群的内部原理
3.1 选举机制
1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2）Zookeeper虽然在配置文件中并没有指定Master[leader]和Slave[follower]。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。
3）以一个简单的例子来说明整个选举的过程。
假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图所示。
图中Zookeeper的选举机制
（1）服务器1启动，此时只有它一台服务器启动了，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。
（2）服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。
（5）服务器5启动，同4一样当小弟。
全新集群选主
以一个简单的例子来说明整个选举的过程：假设有五台服务器组成的 zookeeper 集群，它们 的 serverid 从 1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点 上，都是一样的。假设这些服务器依序启动，来看看会发生什么
（1）服务器 1 启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的 选举状态一直是 LOOKING 状态
（2）服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以 id 值较大的服务器 2 胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是 3)，所以服务器 1、2 还是继续保持 LOOKING 状态
（3）服务器 3 启动，根据前面的理论分析，服务器 3 成为服务器 1,2,3 中的老大，而与上面不 同的是，此时有三台服务器(超过半数)选举了它，所以它成为了这次选举的 leader
（4）服务器 4 启动，根据前面的分析，理论上服务器 4 应该是服务器 1,2,3,4 中最大的，但是 由于前面已经有半数以上的服务器选举了服务器 3，所以它只能接收当小弟的命了
（5）服务器 5 启动，同 4 一样，当小弟
非全新集群选主
那么，初始化的时候，是按照上述的说明进行选举的，但是当 zookeeper 运行了一段时间之 后，有机器 down 掉，重新选举时，选举过程就相对复杂了。
需要加入数据 version、serverid 和逻辑时钟。
Data version：数据新的 version 就大，数据每次更新都会更新 version
server id：就是我们配置的 myid 中的值，每个机器一个
逻辑时钟：这个值从 0 开始递增，每次选举对应一个值，也就是说：如果在同一次选举中， 那么这个值应该是一致的；逻辑时钟值越大，说明这一次选举 leader 的进程更新，也就是 每次选举拥有一个 zxid，投票结果只取 zxid 最大的
选举的标准就变成：
1.逻辑时钟小的选举结果被忽略，重新投票
2.统一逻辑时钟后，数据 version 大的胜出
3.数据 version 相同的情况下，server id 大的胜出
根据这个规则选出 leader。
3.2 节点类型
1.持久节点（Persistent）：服务端和客户端断开连接后，创建的节点不删除；
持久化目录节点：服务端和客户端断开连接后，该节点仍然存在；
持久化顺序编号目录节点：服务端和客户端断开连接后，该节点仍然存在；只是zook给该节点名称进行顺序编号。
2.短暂节点(Ephemeral)：服务端和客户端断开连接后，创建的节点自己删除；
临时目录节点：客户端与Zookeeper断开连接后，该节点被删除
临时顺序编号目录节点：客户端与Zookeeper断开连接后，该节点被删除，只是zook给该节点名称进行顺序编号。
3.3 写和读数据流程
1.写数据流程
以3台服务器的Zookeeper集群为例，一个Leader，两个Follower即server1和server2。
（1）Client向Zookeeper的server1发送一个写请求，客户端写数据到服务器1上；
（2）如果server1不是Leader，那么server1会把接收到的写请求转发给Leader；然后Leader会将写请求转发给每个server；
每个flower，写完都会给leader 一个响应。
（3）当Leader收到集群半数以上的节点写成功的消息后，说明该写操作执行成功；
（4）leader 就成功的结果，响应给server1：
（5）被访问的server1进一步通知client数据写成功，这时，客户端就知道整个写操作成功了。
2.读数据
相比写数据流程，读数据流程就简单得多；因为每台server中数据一致性都一样，所以随便访问哪台server读数据就行；没有写数据流程中请求转发、数据同步、成功通知这些步骤。
第4节：分布式安装部署
4.1 集群规划
在zk01、zk02和zk03三个节点上部署Zookeeper。
4.2 集群中的角色和作用
a.Leader角色
Leader服务器是整个zookeeper集群的核心，主要的工作任务有两项
1. 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
2. 集群内部各服务器的调度者
b.Follower角色
Follower角色的主要职责是
1. 处理客户端非事务请求、转发事务请求给leader服务器
2. 参与Leader选举的投票
3. 能够处理读请求
c.Observer角色
Observer 角色： 类似于Follower ，高版本提供的角色
区别：
不参与leader 投票，其他都类似于Follower 。
4.3 解压安装
（1）解压Zookeeper安装包到/opt/pro/zk目录下
tar -zxvf apache-zookeeper-3.6.2-bin.tar.gz -C /opt/pro/zk
（2）拷贝/opt/pro/zk/apache-zookeeper-3.6.2-bin目录内容到另外两台服务器。
4.4 zk集群配置
四台服务器上分别操作：
（1）zkData目录下创建myid文件： zkData/myid
vim myid
编辑：
文件当中标注： 当前服务器的编号： 1
（2） vim /conf/zoo.cfg 配置文件：
a:zkData 对应的值改变： 填写zkData的目录
b:端口号改变：
c:集群配置
server.1=192.168.1.181:2888:3888
server.2=192.168.1.181:2889:3889
server.3=192.168.1.181:2890:3890
server.A=B:C:D
A：其中 A 是一个数字，表示这个是服务器的编号；
B：是这个服务器的 ip 地址；
C：Zookeeper服务器之间的通信端口。
D：Leader选举的端口；
4.5 集群操作
（1）分别启动Zookeeper
bin/zkServer.sh start
（2）查看状态
bin/zkServer.sh status
注意：第2台机器是leader ，半数机制
（3）客户端连接集群
bin/zkCli.sh -server 192.168.1.181:2186,192.168.1.181:2187,192.168.1.181:2188
第5节：API应用
5.1 创建一个Maven工程
5.2 添加pom文件
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.8.2</version>
</dependency>
<!-- https://mvnrepository.com/artifact/org.apache.zookeeper/zookeeper -->
<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.4.8</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>test</scope>
</dependency>
</dependencies>
5.3 log4j.properties文件
需要在项目的src/main/resources目录下，新建一个文件，命名为“log4j.properties”，在文件中填入。
log4j.rootLogger=INFO, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=%d %p [%c] - %m%n
log4j.appender.logfile=org.apache.log4j.FileAppender
log4j.appender.logfile.File=target/spring.log
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c] - %m%n
5.4 创建客户端
5.4.1 定义实例化Zookeeper
private static String connectString =
"192.168.164.136:2181,192.168.164.137:2181,192.168.164.138:2181";
private static int sessionTimeout = 60000;
private ZooKeeper zkClient = null;
@Before
public void init() throws Exception {
zkClient = new ZooKeeper(connectString, sessionTimeout, new Watcher() {
public void process(WatchedEvent event) {
// 收到事件通知后的回调函数（用户的业务逻辑）
System.out.println(event.getType() + "--" + event.getPath());
// 再次启动监听
try {
zkClient.getChildren("/", true);
} catch (Exception e) {
e.printStackTrace();
}
}
});
}
5.4.2 创建子节点
// 创建子节点
@Test
public void create(){
// 参数1：要创建的节点的路径； 参数2：节点数据 ； 参数3：节点权限 ；参数4：节点的类型
权限说明：
OPEN_ACL_UNSAFE : 完全开放的ACL，任何连接的客户端都可以操作该属性znode
CREATOR_ALL_ACL : 只有创建者才有ACL权限
READ_ACL_UNSAFE：只能读取ACL
try {
String nodeCreated = zkClient.create("/offcn", "youjiuye".getBytes(), ZooDefs.Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
} catch (KeeperException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
5.4.3 获取子节点并监听节点变化
// 获取子节点
@Test
public void getChildren() throws Exception {
/*
getChildren：获得某个节点下的所有的子节点：
/: 根节点：
boolean： 是否监听该节点~
*/
List<String> children = zkClient.getChildren("/", true);
// 延时阻塞
Thread.sleep(Long.MAX_VALUE);
}
5.4.4 判断Znode是否存在
// 判断znode是否存在
@Test
public void exist() throws Exception {
/*
exists:判断节点是否存在： 返回的是一个Stat对象。
对象是null， 该节点不存在。
对象不是null， 该节点存在的。
*/
Stat stat = zkClient.exists("/shuihu", false);
System.out.println(stat == null ? "not exist" : "exist");
}
5.4.5 节点的删除
@Test
public void test5()throws Exception{
/*
delete:节点的删除操作： 节点删除的时候，只能删除单个节点，如果当前节点中有子节点，不能直接删除。
path:删除节点的路径：
version： 当前节点的版本信息： get /test0000000008 获得当前节点的详细信息，version信息
非序列化节点 为-1
*/
zkClient.delete("/test0000000008",0);
}
扩展：ZAB协议，原子广播协议 Zookeeper Atomic Broadcast 解决了Zookeeper 的崩溃恢复和主从数据同步的问题
7419
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
