关于java:史上最便捷搭建-Zookeeper-的方法

47次阅读

共计 8489 个字符，预计需要花费 22 分钟才能阅读完成。

作者：不学有数的程序员 \
链接：www.jianshu.com/p/6d349acf48aa

什么是 ZooKeeper

ZooKeeper 是 Apache 的一个顶级我的项目，为分布式应用提供高效、高可用的分布式协调服务，提供了诸如数据公布 / 订阅、负载平衡、命名服务、分布式协调 / 告诉和分布式锁等分布式根底服务。

因为 ZooKeeper 便捷的应用形式、卓越的性能和良好的稳定性，被宽泛地利用于诸如 Hadoop、HBase、Kafka 和 Dubbo 等大型分布式系统中。

Zookeeper 有三种运行模式：单机模式、伪集群模式和集群模式。

  • 单机模式：这种模式个别实用于开发测试环境，一方面咱们没有那么多机器资源，另外就是平时的开发调试并不需要极好的稳定性。
  • 集群模式：一个 ZooKeeper 集群通常由一组机器组成，个别 3 台以上就能够组成一个可用的 ZooKeeper 集群了。组成 ZooKeeper 集群的每台机器都会在内存中保护以后的服务器状态，并且每台机器之间都会相互放弃通信。
  • 伪集群模式：这是一种非凡的集群模式，即集群的所有服务器都部署在一台机器上。当你手头上有一台比拟好的机器，如果作为单机模式进行部署，就会浪费资源，这种状况下，ZooKeeper 容许你在一台机器上通过启动不同的端口来启动多个 ZooKeeper 服务实例，以此来以集群的个性来对外服务。

ZooKeeper 的相干常识

Zookeeper 中的角色：

  • 领导者（leader）：负责进行投票的发动和决定，更新零碎状态。
  • 跟随者（follower）：用于接管客户端申请并给客户端返回后果，在选主过程中进行投票。
  • 观察者（observer）：能够承受客户端连贯，将写申请转发给 leader，然而 observer 不加入投票的过程，只是为了扩大零碎，进步读取的速度。

Zookeeper 的数据模型

  • 层次化的目录构造，命名合乎惯例文件系统标准，相似于 Linux。
  • 每个节点在 Zookeeper 中叫做 Znode，并且其有一个惟一的门路标识。
  • 节点 Znode 能够蕴含数据和子节点，然而 EPHEMERAL 类型的节点不能有子节点。
  • Znode 中的数据能够有多个版本，比方某一个门路下存有多个数据版本，那么查问这个门路下的数据就须要带上版本。
  • 客户端利用能够在节点上设置监视器。
  • 节点不反对局部读写，而是一次性残缺读写。

ZooKeeper 的节点个性

ZooKeeper 节点是生命周期的，这取决于节点的类型。在 ZooKeeper 中，节点依据持续时间能够分为长久节点（PERSISTENT）、长期节点（EPHEMERAL），依据是否有序能够分为程序节点（SEQUENTIAL）、和无序节点（默认是无序的）。

长久节点一旦被创立，除非被动移除，不然始终会保留在 Zookeeper 中（不会因为创立该节点的客户端的会话生效而隐没）。

Zookeeper 的利用场景

ZooKeeper 是一个高可用的分布式数据管理与零碎协调框架。基于对 Paxos 算法的实现，使该框架保障了分布式环境中数据的强一致性，也正是基于这样的个性，使得 ZooKeeper 解决很多分布式问题。

值得注意的是，ZooKeeper 并非天生就是为这些利用场景设计的，都是起初泛滥开发者依据其框架的个性，利用其提供的一系列 API 接口（或者称为原语集），摸索进去的典型应用办法。

数据公布与订阅（配置核心）

公布与订阅模型，即所谓的配置核心，顾名思义就是发布者将数据公布到 ZooKeeper 节点上，供订阅者动静获取数据，实现配置信息的集中式治理和动静更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合应用。

利用中用到的一些配置信息放到 ZooKeeper 上进行集中管理。这类场景通常是这样：利用在启动的时候会被动来获取一次配置，同时在节点上注册一个 Watcher。这样一来，当前每次配置有更新的时候，都会实时告诉到订阅的客户端，素来达到获取最新配置信息的目标。

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

分布式日志收集零碎

这个零碎的外围工作是收集散布在不同机器的日志。收集器通常是依照利用来调配收集工作单元，因而须要在 ZooKeeper 上创立一个以利用名作为 path 的节点 P，并将这个利用的所有机器 IP，以子节点的模式注册到节点 P 上。这样一来就可能实现机器变动的时候，可能实时告诉到收集器调整任务分配。

零碎中有些信息须要动静获取，并且还会存在人工手动去批改这个信息的提问。通常是暴露出接口，例如 JMX 接口，来获取一些运行时的信息。引入 ZooKeeper 之后，就不必本人实现一套计划了，只有将这些信息寄存到指定的 ZooKeeper 节点上即可。

留神： 在下面提到的利用场景中，有个默认前提——数据量很小，然而数据更新可能会比拟快的场景。

负载平衡

这里说的负载平衡是指 软负载平衡。在分布式环境中，为了保障高可用性，通常同一个利用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中抉择一个来执行相干的业务逻辑，其中比拟典型的是消息中间件中的生产者，消费者负载平衡。

命名服务（Naming Service）

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

阿里巴巴团体开源的分布式服务框架 Dubbo 中应用 ZooKeeper 来作为其命名服务，保护全局的服务地址列表。在 Dubbo 的实现中：

  • 服务提供者在启动的时候，向 ZooKeeper 上的指定节点 /dubbo/${serviceName}/providers 目录下写入本人的 URL 地址，这个操作就实现了服务的公布。
  • 服务消费者启动的时候，订阅 /dubbo/${serviceName}/providers 目录下的提供者 URL 地址，并向 /dubbo/${serviceName} /consumers 目录下写入本人的 URL 地址。

留神： 所有向 ZooKeeper 上注册的地址都是长期节点，这样就可能保障服务提供者和消费者可能主动感应资源的变动。

另外，Dubbo 还有针对服务粒度的监控。办法是订阅 /dubbo/${serviceName} 目录下所有提供者和消费者的信息。

分布式告诉 / 协调

ZooKeeper 中特有 Watcher 注册与异步告诉机制，可能很好的实现分布式环境下不同零碎之间的告诉与协调，实现对数据变更的实时处理。应用办法通常是不同零碎都对 ZooKeeper 上同一个 Znode 进行注册，监听 Znode 的变动（包含 Znode 自身内容及子节点的），其中一个零碎 Update 了 Znode，那么另一个零碎可能收到告诉，并作出相应解决。

另一种心跳检测机制：检测零碎和被检测零碎之间并不间接关联起来，而是通过 ZooKeeper 上某个节点关联，大大减少零碎耦合。

另一种系统调度模式：某零碎有控制台和推送零碎两局部组成，控制台的职责是管制推送零碎进行相应的推送工作。管理人员在控制台作的一些操作，实际上是批改了 ZooKeeper 上某些节点的状态，而 ZooKeeper 就把这些变动告诉给它们注册 Watcher 的客户端，即推送零碎。于是，作出相应的推送工作。

另一种工作汇报模式：一些相似于工作散发零碎。子工作启动后，到 ZooKeeper 来注册一个长期节点，并且定时将本人的进度进行汇报（将进度写回这个长期节点）。这样工作管理者就可能实时晓得工作进度。

分布式锁

分布式锁次要得益于 ZooKeeper 为咱们保障了数据的强一致性。锁服务能够分为两类：一类是放弃独占，另一类是管制时序。

所谓 放弃独占，就是所有试图来获取这个锁的客户端，最终只有一个能够胜利取得这把锁。通常的做法是把 ZooKeeper 上的一个 Znode 看作是一把锁，通过 create znode 的形式来实现。所有客户端都去创立 /distribute_lock 节点，最终胜利创立的那个客户端也即领有了这把锁。

管制时序，就是所有视图来获取这个锁的客户端，最终都是会被安顿执行，只是有个全局时序了。做法和下面根本相似，只是这里 /distribute_lock 曾经事后存在，客户端在它上面创立长期有序节点（这个能够通过节点的属性管制：CreateMode.EPHEMERAL_SEQUENTIAL 来指定）。ZooKeeper 的父节点（/distribute_lock）维持一份 sequence，保障子节点创立的时序性，从而也造成了每个客户端的全局时序。

  1. 因为同一节点下子节点名称不能雷同，所以只有在某个节点下创立 Znode，创立胜利即表明加锁胜利。注册监听器监听此 Znode，只有删除此 Znode 就告诉其余客户端来加锁。
  2. 创立长期程序节点：在某个节点下创立节点，来一个申请则创立一个节点，因为是程序的，所以序号最小的取得锁，当开释锁时，告诉下一序号取得锁。
分布式队列

队列方面，简略来说有两种：一种是惯例的 先进先出队列 ，另一种是 等队列的队员聚齐当前才依照程序执行。对于第一种的队列和下面讲的分布式锁服务中管制时序的场景基本原理统一，这里就不赘述了。

第二种队列其实是在 FIFO 队列的根底上作了一个加强。通常能够在 /queue 这个 Znode 下事后建设一个 /queue/num 节点，并且赋值为 n（或者间接给 /queue 赋值 n）示意队列大小。之后每次有队列成员退出后，就判断下是否曾经达到队列大小，决定是否能够开始执行了。

这种用法的典型场景是：分布式环境中，一个大工作 Task A，须要在很多子工作实现（或条件就绪）状况下能力进行。这个时候，但凡其中一个子工作实现（就绪），那么就去 /taskList 下建设本人的长期时序节点（CreateMode.EPHEMERAL_SEQUENTIAL）。当 /taskList 发现自己上面的子节点满足指定个数，就能够进行下一步按序进行解决了。

应用 dokcer-compose 搭建集群

下面咱们介绍了对于 ZooKeeper 有这么多的利用场景，那么接下来就先学习如何搭建 ZooKeeper 集群而后再进行实战下面的利用场景。

文件的目录构造如下：

├── docker-compose.yml

编写 docker-compose.yml 文件

docker-compose.yml 文件内容如下：

version: '3.4'

services:
  zoo1:
    image: zookeeper
    restart: always
    hostname: zoo1
    ports:
      - 2181:2181
    environment:
      ZOO_MY_ID: 1
      ZOO_SERVERS: server.1=0.0.0.0:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=zoo3:2888:3888;2181

  zoo2:
    image: zookeeper
    restart: always
    hostname: zoo2
    ports:
      - 2182:2181
    environment:
      ZOO_MY_ID: 2
      ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=0.0.0.0:2888:3888;2181 server.3=zoo3:2888:3888;2181

  zoo3:
    image: zookeeper
    restart: always
    hostname: zoo3
    ports:
      - 2183:2181
    environment:
      ZOO_MY_ID: 3
      ZOO_SERVERS: server.1=zoo1:2888:3888;2181 server.2=zoo2:2888:3888;2181 server.3=0.0.0.0:2888:3888;2181

在这个配置文件中，Docker 运行了 3 个 Zookeeper 镜像，通过 ports 字段别离将本地的 2181, 2182, 2183 端口绑定到对应容器的 2181 端口上。

ZOO_MY_ID 和 ZOO_SERVERS 是搭建 Zookeeper 集群须要的两个环境变量。ZOO_MY_ID 标识服务的 id，为 1-255 之间的整数，必须在集群中惟一。ZOO_SERVERS 是集群中的主机列表。

在 docker-compose.yml 所在目录下执行 docker-compose up，能够看到启动的日志。

连贯 ZooKeeper

将集群启动起来当前咱们能够连贯 ZooKeeper 对其进行节点的相干操作。

  1. 首先须要下载 ZooKeeper。
  2. 将其解压。
  3. 进入其 conf/ 目录，将 zoo_sample .cfg 改成 zoo.cfg。

配置文件阐明

# The number of milliseconds of each tick
# tickTime：CS 通信心跳数
# Zookeeper 服务器之间或客户端与服务器之间维持心跳的工夫距离，也就是每个 tickTime 工夫就会发送一个心跳。tickTime 以毫秒为单位。tickTime=2000

# The number of ticks that the initial
# synchronization phase can take
# initLimit：LF 初始通信时限
# 集群中的 follower 服务器 (F) 与 leader 服务器 (L) 之间初始连贯时能容忍的最多心跳数（tickTime 的数量）。initLimit=5

# The number of ticks that can pass between
# sending a request and getting an acknowledgement
# syncLimit：LF 同步通信时限
# 集群中的 follower 服务器与 leader 服务器之间申请和应答之间能容忍的最多心跳数（tickTime 的数量）。syncLimit=2

# the directory where the snapshot is stored.
# do not use /tmp for storage, /tmp here is just
# example sakes.
# dataDir：数据文件目录
# Zookeeper 保留数据的目录，默认状况下，Zookeeper 将写数据的日志文件也保留在这个目录里。dataDir=/data/soft/zookeeper-3.4.12/data


# dataLogDir：日志文件目录
# Zookeeper 保留日志文件的目录。dataLogDir=/data/soft/zookeeper-3.4.12/logs

# the port at which the clients will connect
# clientPort：客户端连贯端口
# 客户端连贯 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，承受客户端的拜访申请。clientPort=2181

# the maximum number of client connections.
# increase this if you need to handle more clients
#maxClientCnxns=60
#
# Be sure to read the maintenance section of the
# administrator guide before turning on autopurge.
#
# http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance
#
# The number of snapshots to retain in dataDir
#autopurge.snapRetainCount=3
# Purge task interval in hours
# Set to "0" to disable auto purge feature
#autopurge.purgeInterval=1


# 服务器名称与地址：集群信息（服务器编号，服务器地址，LF 通信端口，选举端口）# 这个配置项的书写格局比拟非凡，规定如下：# server.N=YYY:A:B

# 其中 N 示意服务器编号，YYY 示意服务器的 IP 地址，A 为 LF 通信端口，示意该服务器与集群中的 leader 替换的信息的端口。B 为选举端口，示意选举新 leader 时服务器间互相通信的端口（当 leader 挂掉时，其余服务器会互相通信，抉择出新的 leader）。一般来说，集群中每个服务器的 A 端口都是一样，每个服务器的 B 端口也是一样。然而当所采纳的为伪集群时，IP 地址都一样，只能时 A 端口和 B 端口不一样。

能够不批改 zoo.cfg，应用默认配置。接下来在解压后的 bin/ 目录中执行命令 ./zkCli.sh -server 127.0.0.1:2181 就能进行连贯了。

Welcome to ZooKeeper!
2020-06-01 15:03:52,512 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1025] - Opening socket connection to server localhost/127.0.0.1:2181. Will not attempt to authenticate using SASL (unknown error)
JLine support is enabled
2020-06-01 15:03:52,576 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@879] - Socket connection established to localhost/127.0.0.1:2181, initiating session
2020-06-01 15:03:52,599 [myid:] - INFO  [main-SendThread(localhost:2181):ClientCnxn$SendThread@1299] - Session establishment complete on server localhost/127.0.0.1:2181, sessionid = 0x100001140080000, negotiated timeout = 30000

WATCHER::

WatchedEvent state:SyncConnected type:None path:null
[zk: 127.0.0.1:2181(CONNECTED) 0]

接下来能够应用命令查看节点：

应用 ls 命令查看以后 ZooKeeper 中所蕴含的内容。

命令：ls /

[zk: 127.0.0.1:2181(CONNECTED) 10] ls /[zookeeper]

创立了一个新的 znode 节点 zk 以及与它关联的字符串。

命令：create /zk myData

[zk: 127.0.0.1:2181(CONNECTED) 11] create /zk myDataCreated /zk[zk: 127.0.0.1:2181(CONNECTED) 12] ls /[zk, zookeeper][zk: 127.0.0.1:2181(CONNECTED) 13]

获取 znode 节点 zk。

命令：get /zk

[zk: 127.0.0.1:2181(CONNECTED) 13] get /zkmyDatacZxid = 0x400000008ctime = Mon Jun 01 15:07:50 CST 2020mZxid = 0x400000008mtime = Mon Jun 01 15:07:50 CST 2020pZxid = 0x400000008cversion = 0dataVersion = 0aclVersion = 0ephemeralOwner = 0x0dataLength = 6numChildren = 0

删除 znode 节点 zk。命令：delete /zk

[zk: 127.0.0.1:2181(CONNECTED) 14] delete /zk[zk: 127.0.0.1:2181(CONNECTED) 15] ls /[zookeeper]

因为篇幅无限，在接下来的文章中会依据下面提到的 ZooKeeper 利用场景逐个进行用代码进行实现。最初，关注公众号 Java 技术栈，在后盾回复：面试，能够获取我整顿的 Java、ZK 系列面试题和答案，十分齐全。

近期热文举荐：

1.600+ 道 Java 面试题及答案整顿(2021 最新版)

2. 终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3. 阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！

正文完
java
发表至： java
2021-05-31
 0
关于java:设计模式工厂方法以及SpringBoot注入整合附实例
关于java:Shiro
leetCode001
关于java:Javadoc文档生成方式