Zookeeper概念&集群搭建

CY 2018年05月26日 942次浏览

参考教程：https://www.w3cschool.cn/zookeeper/

Zookeeper中的角色

Leader（之前的版本中叫做Master）:

  • Zookeeper 集群工作的核心

    因为他是Zookeeper中被选举出来的“老大“

  • 事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性

    所有的修改操作必须要经过他，他必须要保证这些修改执行顺序，比如说一个请求删除了一个数据，紧接着另外一个请求又来更新该数据，这是不能被允许的

  • 集群内部各个服务器的调度者

    对于 create，setData，delete 等有写操作的请求，则需要统一转发给leader 处理，leader 需要决定编号、执行操作，这个过程称为一个事务。

Follower（之前的版本中叫做Slaver）:

  • 处理客户端非事务（读操作）请求，转发事务请求给 Leader

    如果客户端只是来查询一条数据，那么直接由Follower来进行，如果客户端是要进行数据的修改，那么会由Leader来进行

  • 参与集群 Leader 选举投票

此外，针对访问量比较大的 zookeeper 集群，还可新增观察者角色。

Observer（观察者角色）:

观察 Zookeeper 集群的最新状态变化并将这些状态同步过来，其对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理。

不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

集群的搭建

  1. 需要提前安装JDK

  2. 检测集群机器的时间是否同步（批量发送命令date，然后对比机器的时间）

  3. 检测防火墙是否关闭

    使用命令：firewall-cmd --state 查看防火墙的状态

    如果防火墙没有关闭的话执行systemctl stop firewalld.service

    如果不想防火墙开机启动的话systemctl stop firewalld.service

  4. 检测主机名和IP之间的映射有没有配置

    例如:

    # /etc/hosts文件中添加：
192.168.125.129 mini001
192.168.125.130 mini002
192.168.125.131 mini003

  5. 上传安装包到服务器中

上传安装包到服务器中.png

  1. 修改Zookeeper的配置

    首先到Zookeeper的目录下conf文件夹下拷贝出zoo.cfg

    zoo.cfg.png

    打开zoo.cfg文件修改数据目录，例如：

    修改数据目录.png

    添加集群配置到配置文件中（添加到文件末尾即可）

    server.1=mini001:2888:3888
server.2=mini002:2888:3888
server.3=mini003:2888:3888

    第一个端口号为心跳端口，第二个端口号为选举端口

    添加集群配置到配置文件.png

  2. 在data文件夹下创建myid文件内容为服务器编号也就是上面server.X中的X

    myid文件.png

  3. 将第一台服务器上配置好的Zookeeper发送到其他服务器上

    为了方便发送我们可以设置服务器之间的免密访问

    免密登陆的方法：

    ssh-keygen命令生成密钥

    生成密钥.png

    ssh-copy-id IP把生成的密钥copy到其他服务器中

    把生成的密钥copy到其他服务器中.png

    然后就可以免密码登陆其他服务器了

    接下来就可以复制文件到其他服务器上了

    执行下面命令：

    执行.png

  4. 多台服务器同时启动Zookeeper

    多台服务器同时启动Zookeeper.png

    然后查看Zookeeper的状态

    Zookeeper的状态.png

    Zookeeper的状态 .png 发现现在已经自动选举出来一个Leader

ZooKeeper 数据模型（了解）

ZooKeeper 的数据模型，在结构上和标准文件系统的非常相似，拥有一个层次的命名空间，都是采用树形层次结构，ZooKeeper 树中的每个节点被称为—Znode。和文件系统的目录树一样，ZooKeeper 树中的每个节点可以拥有子节点。

但也有不同之处：

  1. Znode兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分，并可以具有子 Znode。用户对 Znode 具有增、删、改、查等操作（权限允许的情况下）。

  2. Znode具有原子性操作，读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的 ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。

  3. Znode存储数据大小有限制。ZooKeeper 虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以 KB 为大小单位。ZooKeeper 的服务器和客户端都被设计为严格检查并限制每个 Znode 的数据大小至多 1M，当时常规使用中应该远小于此值。

  4. Znode通过路径引用，如同 Unix 中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在 ZooKeeper 中，路径由Unicode 字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。

数据结构图

数据结构图.png

图中的每个节点称为一个 Znode。 每个 Znode 由 3 部分组成:

​ ① stat：此为状态信息, 描述该 Znode 的版本, 权限等信息

​ ② data：与该 Znode 关联的数据

​ ③ children：该 Znode 下的子节点

节点类型（了解）

Znode 有两种，分别为临时节点和永久节点。

节点的类型在创建时即被确定，并且不能改变。

临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删除。临时节点不允许拥有子节点。

永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

Znode 还有一个序列化的特性，如果创建的时候指定的话，该 Znode 的名字后面会自动追加一个不断增加的序列号。序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为“%10d”(10 位数字，没有数值的数位用 0 补充，例如“0000000001”)。

Znode序列号.png

这样便会存在四种类型的 Znode 节点，分别对应：

PERSISTENT：永久节点

EPHEMERAL：临时节点

PERSISTENT_SEQUENTIAL：永久节点、序列化

EPHEMERAL_SEQUENTIAL：临时节点、序列化

节点属性（了解）

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

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

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

aclVersion ：ACL 的版本号。

cZxid ：Znode 创建的事务 id。

mZxid ：Znode 被修改的事务 id，即每次对 znode 的修改都会更新 mZxid。

对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeper Transaction Id）。通过 zxid，可以确定更新操作的先后顺序。例如，如果 zxid1小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，即使操作的是不同的 znode。

ctime：节点创建时的时间戳.

mtime：节点最新一次更新发生时的时间戳.

ephemeralOwner:如果该节点为临时节点, ephemeralOwner 值表示与该节点绑定的 session id. 如果不是，ephemeralOwner 值为 0.

在 client 和 server 通信之前,首先需要建立连接,该连接称为 session。连接建立后,如果发生连接超时、授权失败,或者显式关闭连接,连接便处于 CLOSED状态, 此时 session 结束。

Zookeeper的Shell客户端操作

客户端连接

运行 zkCli.sh –server ip 进入命令行工具。

输入 help，输出 zk shell 提示：

Help命令.png

shell 基本操作

创建节点

create [-s] [-e] path data acl

其中，-s 或-e 分别指定节点特性，-s顺序或-e临时节点，若不指定，则表示持久节点；acl 用来进行权限控制。

创建顺序节点：

顺序节点.png

创建临时节点：

临时节点.png

创建永久节点：

永久节点.png

读取节点

与读取相关的命令有 ls 命令和 get 命令

ls 命令可以列出 Zookeeper 指定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点

get 命令可以获取 Zookeeper 指定节点的数据内容和属性信息。

ls path [watch]

ls path watch.png

get path [watch]

get path watch.png

ls2 path [watch]

ls2 path watch

更新节点

set path data [version]

data 就是要更新的新内容，version 表示数据版本。

dataVersion 0.png

dataVersion 1.png

现在 dataVersion 已经变为 1 了，表示进行了更新。

删除节点

delete path [version]

若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。

删除前.png

删除后.png

rmr path可以递归删除节点。

quota为节点增加限制

setquota -n|-b val path # 对节点增加限制

-n:表示子节点的最大个数

-b:表示数据值的最大长度

val:子节点最大个数或数据值的最大长度

path:节点路径

节点路径.png

listquota path # 列出指定节点的 quota

listquota path.png

子节点个数为 3,数据长度-1 表示没限制

delquota [-n|-b] path  # 删除 quota

delquota.png

子节点个数为-1，没有限制

history 查看

history : 列出命令历史

列出命令历史.png

redo：该命令可以重新执行指定命令编号的历史命令,命令编号可以通过

重新执行指定命令.png

ZooKeeper Watcher

ZooKeeper 提供了分布式数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。ZooKeeper 中，引入了 Watcher 机制来实现这种分布式的通知功能。ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

触发事件种类很多，如：节点创建，节点删除，节点改变，子节点改变等。

总的来说可以概括 Watcher 为以下三个过程：

客户端向服务端注册 Watcher

服务端事件发生触发 Watcher

客户端回调 Watcher 得到触发事件情况

Watch 机制特点

一次性触发

事件发生触发监听，一个 watcher event 就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。

事件封装

ZooKeeper 使用 WatchedEvent 对象来封装服务端事件并传递。

WatchedEvent 包含了每一个事件的三个基本属性：

  • 通知状态（keeperState）

  • 事件类型（EventType）

  • 节点路径（path）

event 异步发送

watcher 的通知事件从服务端发送到客户端是异步的。

先注册再触发

Zookeeper 中的 watch 机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端。

通知状态和事件类型

同一个事件类型在不同的通知状态中代表的含义有所不同，下表列举了常见的通知状态和事件类型。

KeeperStateEventType触发条件说明
None (-1)客户端与服务端成功建立连接
SyncConnected (0)NodeCreated (1)Watcher监听的对应数据节点被创建
NodeDeleted (2)Watcher监听的对应数据节点被删除此时客户端和服务器处于连接状态
NodeDataChanged (3)Watcher监听的都应数据节点的数据内容发生变更
NodeChildChanged (4)Wather 监听的对应 数据节点的子节点列 表发生变更
Disconnected (0)None (-1)客户端与ZooKeeper 服务器断开连接此时客户端和服务器处于断开连接状态
Expired (-112)None (-1)会话超时此时客户端会话失效，通常同时也会受到SessionExpiredException异常
AuthFailed (4)None (-1)通常有两种情况， 1：使用错误的 schema 进行权限检 查 2：SASL 权限检 查失败通常同时也会收到 AuthFailedException 异常

其中连接状态事件(type=None, path=null)不需要客户端注册，客户端只要有需要直接处理就行了。

Shell 客户端设置 watcher

可以使用Watcher的命令通常会在命令后面标明，例如：

使用Watcher的命令通常会在命令后面标明.png

设置节点数据变动监听：

设置节点数据变动监听.png

通过另一个客户端更改节点数据：

通过另一个客户端更改节点数据.png

此时设置监听的节点收到通知：

设置监听的节点收到通知.png

Java操作Zookeeper

ZooKeeper Java API

org.apache.zookeeper.Zookeeper

Zookeeper 是在 Java 中客户端主类，负责建立与 Zookeeper 集群的会话，并提供方法进行操作。

org.apache.zookeeper.Watcher

Watcher 接口表示一个标准的事件处理器，其定义了事件通知相关的逻辑，包含 KeeperState 和 EventType 两个枚举类，分别代表了通知状态和事件类型，同时定义了事件的回调方法：process（WatchedEvent event）。

process 方法是 Watcher 接口中的一个回调方法，当 ZooKeeper 向客户端发送一个 Watcher 事件通知时，客户端就会对相应的 process 方法进行回调，从而实现对事件的处理。

基本使用

建立 java maven 项目,引入 maven pom 坐标。

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

import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooDefs.Ids;
import org.apache.zookeeper.ZooKeeper;

public class ZookeeperDemo {

	public static void main(String[] args) throws Exception {
		// 初始化 ZooKeeper 实例(zk 地址、会话超时时间，与系统默认一致、watcher)
		ZooKeeper zk = new ZooKeeper("192.168.125.129:2181,192.168.125.130:2181", 30000, new Watcher() {
			@Override
			public void process(WatchedEvent event) {
				System.out.println("事件类型为：" + event.getType());
				System.out.println("事件发生的路径：" + event.getPath());
				System.out.println("通知状态为：" + event.getState());
			}
		});
		zk.create("/myGirls", "性感的".getBytes("UTF-8"), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
		zk.close();
	}
}

运行结果.png

更多操作示例

import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooDefs.Ids;
import org.apache.zookeeper.ZooKeeper;

public class ZookeeperDemo {

	public static void main(String[] args) throws Exception {
		// 初始化 ZooKeeper 实例(zk 地址、会话超时时间，与系统默认一致、watcher)
		ZooKeeper zk = new ZooKeeper("192.168.125.129:2181,192.168.125.130:2181", 30000, new Watcher() {
			@Override
			public void process(WatchedEvent event) {
				System.out.println("事件类型为：" + event.getType());
				System.out.println("事件发生的路径：" + event.getPath());
				System.out.println("通知状态为：" + event.getState());
			}
		});
		// 创建一个目录节点
		zk.create("/testRootPath", "testRootData".getBytes(), Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT);
		// 创建一个子目录节点
		zk.create("/testRootPath/testChildPathOne", "testChildDataOne".getBytes(), Ids.OPEN_ACL_UNSAFE,
				CreateMode.PERSISTENT);
		System.out.println(new String(zk.getData("/testRootPath", false, null)));
		// 取出子目录节点列表
		System.out.println(zk.getChildren("/testRootPath", true));
		// 修改子目录节点数据
		zk.setData("/testRootPath/testChildPathOne", "modifyChildDataOne".getBytes(), -1);
		System.out.println("目录节点状态：[" + zk.exists("/testRootPath", true) + "]");
		// 创建另外一个子目录节点
		zk.create("/testRootPath/testChildPathTwo", "testChildDataTwo".getBytes(), Ids.OPEN_ACL_UNSAFE,
				CreateMode.PERSISTENT);
		System.out.println(new String(zk.getData("/testRootPath/testChildPathTwo", true, null)));
		// 删除子目录节点
		zk.delete("/testRootPath/testChildPathTwo", -1);
		zk.delete("/testRootPath/testChildPathOne", -1);
		// 删除父目录节点
		zk.delete("/testRootPath", -1);
		zk.close();
	}
}

运行结果.png

ZooKeeper 选举机制

zookeeper 默认的算法是 FastLeaderElection，采用投票数大于半数则胜出的逻辑。

概念

服务器 ID

比如有三台服务器，编号分别是 1,2,3。

编号越大在选择算法中的权重越大（搭建集群的时候设置的myid）

选举状态

LOOKING，竞选状态。

FOLLOWING，随从状态，同步 leader 状态，参与投票。

OBSERVING，观察状态,同步 leader 状态，不参与投票。

LEADING，领导者状态。

数据 ID

服务器中存放的最新数据 version。

值越大说明数据越新，在选举算法中数据越新权重越大。

为什么值越大权重越大？

每次修改的时候都要修改dataversion，所以哪台机器上的dataversion比较大，意味着这台机器上的数据比较全面，所以权重越大。

逻辑时钟

也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。

也就是每次参加投票都要更新逻辑时钟，如果投票了好几次后几台机器的逻辑时钟还是一样，那么说明这几台机器没有丢下过一次投票，也就是说，投票的时候没有宕机，所以优先选择没有宕机的

全新集群选举

假设目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

  1. 服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息，服务器1的状态一直属于 Looking。

  2. 服务器 2 启动，给自己投票，同时与之前启动的服务器 1 交换结果，由于服务器 2 的编号大所以服务器 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 LOOKING。

  3. 服务器 3 启动，给自己投票，同时与之前启动的服务器 1,2 交换信息，由于服务器 3 的编号最大所以服务器 3 胜出，此时投票数正好大于半数，所以服务器 3 成为领导者，服务器 1,2 成为小弟。

  4. 服务器 4 启动，给自己投票，同时与之前启动的服务器 1,2,3 交换信息，尽管服务器 4 的编号大，但之前服务器 3 已经胜出，所以服务器 4 只能成为小弟。

  5. 服务器 5 启动，后面的逻辑同服务器 4 成为小弟。

非全新集群选举

对于运行正常的 zookeeper 集群，中途有机器 down 掉，需要重新选举时，选举过程就需要加入数据 ID、服务器 ID 和逻辑时钟。

数据 ID：数据新的 version 就大，数据每次更新都会更新 version。

服务器 ID：就是我们配置的 myid 中的值，每个机器一个。

逻辑时钟：这个值从 0 开始递增,每次选举对应一个值。 如果在同一次选举

中,这个值是一致的。

这样选举的标准就变成：

  1. 逻辑时钟小的选举结果被忽略，重新投票；

  2. 统一逻辑时钟后，数据 id 大的胜出；

  3. 数据 id 相同的情况下，服务器 id 大的胜出；

根据这个规则选出 Leader。

Zookeeper的用途

数据发布与订阅（配置中心）

发布与订阅模型，即所谓的注册中心，顾名思义就是发布者将数据发布到 ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。

应用在启动的时候会主动来获取一次配置，同时，在节点上注册一个 Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的。

比如：

分布式搜索服务中，索引的元信息和服务器集群机器的节点状态存放在ZK的一些指定节点，供各个客户端订阅使用。

注意：适合数据量很小的场景，这样数据更新可能会比较快。

命名服务(Naming Service)

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

阿里巴巴集团开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务，维护全局的服务地址列表。

分布式锁

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

所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把 zk 上的一个 znode 看作是一把锁，通过 create znode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。

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

上一篇： Hibernate注解备忘