分布式专题（4）- Zookeeper

最新推荐文章于 2021-09-01 21:34:17 发布

抓娃小兵

最新推荐文章于 2021-09-01 21:34:17 发布

阅读量6.5k

点赞数

分类专栏：分布式专题文章标签： zookeeper 分布式服务协调

本文链接：https://blog.csdn.net/HelloWorld_In_Java/article/details/97775838

版权

分布式专题专栏收录该内容

7 篇文章 0 订阅

订阅专栏

本篇一句话总结：ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能。

正文开始：

什么是Zookeeper？
为什么选择Zookeeper?
怎么用Zookeeper？

上面这几个问题，是每个刚接触Zookeeper的人都想知道的。下面小兵综合自己的理解和使用情况，在分布式专题里总结一篇关于Zookeeper的内容。全文看完，我们对Zookeeper也有一定的了解了。

什么是Zookeeper?

总结一句话，就是：

ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能。

从这句话我们可以知道 Zookeeper 的基本定位是作为一个分布式服务协调框架，能够提供配置管理、统一命名服务、转态同步服务、管理集群、分布式锁和分布式队列等功能。

为什么选择Zookeeper?

在讲《分布式专题（2）- 分布式 Java通信》时我们说过，所谓分布式，无非就是“将一个系统拆分成多个子系统并散布到不同设备”的过程而已。在微服务的大潮之中，我们把系统拆分成了多个服务，根据需要部署在多个机器上，这些服务非常灵活，单个或几个系统的故障不会使整个系统出现故障。并且可以随着访问量弹性扩展，能够持续不间断地提供服务。

虽然分布式应用给我们带来了诸多好处，但拆分系统的同时也带来了巨大的复杂性，我们要写一个分布式应用还是非常困难的，如需要处理分布式session、分布式跨域、分布式任务调度、分布式事务、分布式锁、分布式局部故障等问题。如局部故障问题，一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。他可能在网络故障前就收到了此消息，也可能没有收到，又或者可能接收方的进程死了。发送方了解情况的唯一方法就是再次连接接收方，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制。协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器。协调服务非常容易出错，并很难从故障中恢复。例如：协调服务很容易处于竞态甚至死锁。Zookeeper的设计目的，就是为了减轻分布式应用程序所承担的协调任务。

Zookeeper并不能阻止局部故障的发生，因为它们的本质是分布式系统。他当然也不会隐藏局部故障。ZooKeeper的目的就是提供一些工具集，用来建立安全处理局部故障的分布式应用。

ZooKeeper是一个分布式小文件系统，并且被设计为高可用性（数据保持在内存中）。通过选举算法和集群复制可以避免单点故障，由于是文件系统，所以即使所有的ZooKeeper节点全部挂掉，数据也不会丢失，重启服务器之后，数据即可恢复。另外ZooKeeper的节点更新是原子的，也就是说更新不是成功就是失败。通过版本号，ZooKeeper实现了更新的乐观锁，当版本号不相符时，则表示待更新的节点已经被其他客户端提前更新了，而当前的整个更新操作将全部失败。当然所有的一切ZooKeeper已经为开发者提供了保障，我们需要做的只是调用API。与此同时，随着分布式应用的的不断深入，需要对集群管理逐步透明化监控集群和作业状态，可以充分利ZK的独有特性。

总结上面的几段话，得出选择使用Zookeeper的原因就是：

大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程；
大部分分布式应用需要开发私有的协调程序，缺乏一个通用的机制；
协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器；
ZooKeeper提供了通用且高可用的分布式服务，用以协调分布式应用

所以我们说ZooKeeper是一种分布式协调服务，重在协调二字。下面，我们先把Zookeeper下载回来安装，结合实例，一起来认识和理解“ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能”的含义。

Zookeeper安装

一、下载Zookeeper包（本篇以zookeeper-3.4.10为例）

可以自己前往官网下载，也可以在百度云（https://pan.baidu.com/s/1rzp2U2-yE3BXsD-akJcxzw 提取码：basa ）下载。

二、提取tar文件

# tar -zxvf zookeeper-3.4.10.tar.gz
# cd zookeeper-3.4.10

三、重命名配置文件zoo_sample.cfg

cp conf/zoo_sample.cfg conf/zoo.cfg

四、启动zookeeper

bin/zkServer.sh start

五：检测是否成功启动，用zookeeper客户端连接下服务端

bin/zkCli.sh

出现 Welcome to ZooKeeper! 字样即启动成功。

（zkCli需要依赖JAVA_HOME的环境变量，如果没有，需要在 /etc/profile 中添加）

另外：

zookeeper的初始配置文件zoo_sample.cfg中各配置项意义如下：

# tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间(ms)就会发送一个心跳
tickTime=2000  
# dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataDir=/tmp/zookeeper
# clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
clientPort=2181
# 集群中的follower服务器(F)与leader服务器(L)之间 初始连接 时能容忍的最多心跳数（tickTime的数量），当超过设置倍数的 tickTime 时间，则连接失败。
initLimit=10
# 集群中的follower服务器(F)与leader服务器(L)之间 请求和应答 之间能容忍的最多心跳数（tickTime的数量）。
syncLimit=5

zookeeper的服务端、客户端命令相关参数如下

zkServer.sh {start|start-foreground|stop|restart|status|upgrade|print-cmd}
zkCli.sh -server  ip:port

Zookeeper数据模型

（此部分参考博客：Zookeeper入门看这篇就够了）

ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能。具体是通过它独特的数据结构来实现的，我们可以认为 Zookeeper = 文件系统+监听通知机制。下面我们看一下它的数据结构：

文件系统

在Zookeeper的数据结构中，每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

有持久、持久有序、临时、临时有序四种类型的znode：

PERSISTENT（持久节点）：客户端与zookeeper断开连接后，该节点依旧存在
PERSISTENT_SEQUENTIAL（持久有序节点）：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
EPHEMERAL（临时节点）：客户端与zookeeper断开连接后，该节点被删除
EPHEMERAL_SEQUENTIAL（临时有序节点）：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

通知机制

zookeeper客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

我们说 Zookeeper = 文件系统+监听通知机制，好像看起来挺简单的啊（E=mc²看起来也挺简单的），它怎么就能通过这么简单两点东西，实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理等功能呢？我们看一个它实现配置管理功能的例子，就大概知道它是怎么实现其它功能了。

配置管理

假设我们的程序是分布式部署在多台机器上，如果我们要改变程序的配置文件，需要逐台机器去修改，非常麻烦，现在把这些配置全部放到zookeeper上去，保存在 zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 zookeeper 的通知，然后从 zookeeper 获取新的配置信息应用到系统中。

是不是通过配置管理这个例子，对Zookeeper的了解就更清晰了？还有另外一个经典用法，如下

如上图所示,系统A发送一个请求到MQ，然后系统B消费消息之后处理了。那系统A如何知道系统B的处理结果?

用ZK就可实现分布式系统之间的协调工作!

系统A发送请求之后可以在ZK上对某个节点的值注册监听器，一旦系统B处理完了就修改ZK那个节点的值，A立马就可以收到通知。

通过上面这两个例子，我们对 “Zookeeper = 文件系统+监听通知机制，ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能”可以有更形象地理解。

下面我们就看看Zookeeper一些基本命令，如节点的增删改查等，然后通过Zookeeper提供的API，一起用Java代码实现配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能。

Zookeeper基本命令

Zookeeper是用来解决分布式应用中经常遇到的数据管理问题，对于数据，那基础的无非都是增删改查。下面我们启动zookeeper服务端，然后启动zookeeper客户端，一起敲一下它增删改查的命令。

zookeeper基本的五个命令为 ls 、 create 、 delete 、 set 、get 。输入-h可以查看所有命令，相关命令示例可参考这里。

下面开始使用

1、使用 ls 命令来查看当前 ZooKeeper 中所包含的内容（默认只有zookeeper一个节点）

2、创建一个新的 znode ，使用 create /zkPro myData

3、再次使用 ls 命令来查看现在 zookeeper 中所包含的内容：

4、下面我们运行 get 命令来确认第二步中所创建的 znode 是否包含我们所创建的字符串：

5、下面我们通过 set 命令来对 zk 所关联的字符串进行设置：

6、下面我们将刚才创建的 znode 删除

可以看到，客户端中对节点进行增删改查的命令还是非常简单的。下面看一下在Java代码中如何实现。

Zookeeper提供Java API

1.通过maven引入zookeeper API的jar包

<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>3.4.10</version>
</dependency>

2.启动zookeeper服务端，客户端，并查看节点信息（此处我把2181改成了12181端口）

zkServer.sh start
zkCli.sh -server localhost:12181
ls /

3.通过Java API获取Zookeeper对象并查看节点信息。

（初始化zk客户端时，可以看到需要输入一个sessionTimeout时间，这个会话超时时间也是有点讲究的。）

执行后可得结果：

可以看到，Zookeeper API中对节点进行增删改查的命令还是非常简单的。Zookeeper客户端提供了基本的操作，比如，创建会话、创建节点、读取节点、更新数据、删除节点和检查节点是否存在等。但对于我们开发人员来说，Zookeeper提供的基本操纵还是有一些不足之处，因此，另外两款开源框架ZKClient和Curator又被人们开发了出来，此处更推荐使用Curator。

Zookeeper集群

以上的讲解中都是基于单机模式，这种模式下，如果当前主机宕机，那么所有依赖于当前zookeeper服务工作的其他服务器都不能在进行正常工作，这种事件称为单节点故障。所以这种模式一般用在测试环境。为了防止这种情况出现，生产环境一般都是会在多台机器上配置zookeeper来组成集群，以实现容错和高可用。集群就涉及到数据一致性的问题，即集群中的的数据都应该要保持同步。为此，zookeeper集群引入了Leader、Follower的概念。即对来自于Client的写服务（Write Requst），都会被转发到Leader节点来处理，Leader节点会对这次的更新发起投票，并且发送提议消息给集群中的其他节点，当半数以上的Follower节点将本次修改持久化成功之后，Leader 节点会认为这次写请求处理成功了，提交本次的事务。而来自于Client的读服务（Read Requst），是直接由对应Server的本地副本来进行服务的。具体可以参考Zookeeper一致性原理(ZAB协议)，另外此处补充几个著名的分布式理论。

zookeeper搭建集群也很简单，只需要简单的几步即可完成。

（在一台机器上搭建多个zookeeper就是俗称的伪集群了，资源有限，此处模拟搭建的是伪集群）

1.修改zoo.cfg配置文件

在conf下将zoo_sample.cfg复制为zoo-1.cfg并修改内容如下（其它配置不用动，只修改目录和端口，并添加集群信息）：

dataDir=/tmp/zookeeper-1
clientPort=2181
server.1=127.0.0.1:12181:13181
server.2=127.0.0.1:12182:13182
server.3=127.0.0.1:12183:13183

对比单机模式，配置zk集群时配置文件只需要添加一句：server.id=ip:port1:port2 即可，配置3条即指集群中有3个zk。

可以看到zookeeper的配置中有三个端口，其作用如下：

clientPort：表示与服务端与 clinet 端交换信息的端口号；
port1：表示follower节点与leader节点交换信息的端口号；
port2：表示leader节点挂掉了, 来重新选举leader需要的端口号。

2.复制zoo-1.cfg配置文件

再从zoo-1.cfg复制两个配置文件zoo-2.cfg和zoo-3.cfg，只需修改dataDir和clientPort不同即可，其它配置保存不变。

# zoo2.cfg中的目录和clientPort:
dataDir=/tmp/zookeeper-2
clientPort=2182

# zoo3.cfg中的目录和clientPort:
dataDir=/tmp/zookeeper-3
clientPort=2183

3.创建dataDir目录和标识server.id

每个人都有自己的身份证，每台电脑都有自己的Mac地址，每个zookeeper也有自己唯一标识，就是 server.id 中的id，这个值需要记录在 dataDir 的 myid 文件中。所以我们要为集群中的zookeeper创建这个myid文件，内容就是我们zoo.cfg中配置的id。

# 创建zoo-1.cfg对应的目录及server.id
mkdir /tmp/zookeeper-1
vim /tmp/zookeeper-1/myid
1

# 创建zoo-2.cfg对应的目录及server.id
mkdir /tmp/zookeeper-2
vim /tmp/zookeeper-2/myid
2

# 创建zoo-3.cfg对应的目录及server.id
mkdir /tmp/zookeeper-3
vim /tmp/zookeeper-3/myid
3

4.启动集群实例

bin/zkServer.sh start conf/zoo-1.cfg
bin/zkServer.sh start conf/zoo-2.cfg
bin/zkServer.sh start conf/zoo-3.cfg

5.检测集群状态

bin/zkServer.sh status conf/zoo-1.cfg
bin/zkServer.sh status conf/zoo-2.cfg
bin/zkServer.sh status conf/zoo-3.cfg

可以看到，有一台leader、两台作为follower，集群启动成功。选举过程可以参看这里。

可以通过多个客户端连接集群中不同的机器，并修改其中一台机器上的数据，观察数据是否会同步更新到其它机器上
可以通过安装zookeeper图形化界面来更方便地观察zk的节点信息和对zk节点进行增删改查

终于把zookeeper的基本使用和集群讲完了。接下来，我们就一起再次理解“ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能”这句话。

zk实现分布式应用配置管理

大型应用通常会按业务拆分成一个个业务子系统，这些大大小小的子应用，往往会使用一些公用的资源，比如：需要文件上传、下载时，各子应用都会访问公用的Ftp服务器。如果把Ftp Server的连接IP、端口号、用户名、密码等信息，配置在各子应用中，然后这些子应用再部署到服务器集群中的N台Server上，突然有一天，Ftp服务器要换IP或端口号，那么问题来了？如何快速的把这一堆已经在线上运行的子应用，通通换掉相应的配置，而且还不能停机？

传送门：ZooKeeper 统一配置管理

zk实现统一命名服务

命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。

zk实现状态同步服务

选完Leader以后，zk就进入状态同步过程。
1. Leader等待其它server连接；
2 .Follower连接leader，将最大的zxid发送给leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知follower 已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

zk实现集群管理

Zookeeper 能够很容易的实现集群管理的功能，如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。

所以集群管理无在乎两点：是否有机器退出和加入、选举master。对于第一点，所有机器约定在父目录下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它删除了。新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了。对于第二点“选举master”，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。（即当这个最小编号的 Server 死去，由于是 EPHEMERAL 节点，死去的 Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点，我们就选择这个节点为当前 Master。这样就实现了动态选择 Master，避免了传统意义上单 Master 容易出现单点故障的问题。）

zk实现分布式锁

分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。
控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已经预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序。

zk实现分布式队列

队列方面，简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。

第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点，并且赋值为n（或者直接给/queue赋值n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。

zk实现负载均衡

把ZooKeeper作为一个服务的注册中心，在其中登记每个服务，每台服务器知道自己是属于哪个服务，在服务器启动时，自己向所属服务进行登记，这样，一个树形的服务结构就呈现出来了

服务的调用者到注册中心里面查找：能提供所需服务的服务器列表，然后自己根据负载均衡算法，从中选取一台服务器进行连接

调用者取到服务器列表后，就可以缓存到自己内部，省得下次再取，当服务器列表发生变化，例如某台服务器宕机下线，或者新加了服务器，ZooKeeper会自动通知调用者重新获取服务器列表

由于ZooKeeper并没有内置负载均衡策略，需要调用者自己实现，这个方案只是利用了ZooKeeper的树形数据结构、watcher机制等特性，把ZooKeeper作为服务的注册和变更通知中心。常用的负载均衡算法有：轮询法、随机法、源地址哈希法、加权轮询法、加权随机法、最小连接数法等

抓娃小兵

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
0
评论
分布式专题（4）- Zookeeper

本篇一句话总结：ZooKeeper是一种分布式协调服务，可以实现分布式应用配置管理、统一命名服务、状态同步服务、集群管理、分布式锁和分布式队列等功能。正文开始：什么是Zookeeper？为什么选择Zookeeper? 怎么用Zookeeper？上面这几个问题，是每个刚接触Zookeeper的人都想知道的。下面小兵综合自己的理解和使用情况，在分布式专题里总结一篇关于Zo...
复制链接

扫一扫