当前位置：首页 > news >正文

ZooKeeper安装与配置集群

news 文章来源：https://blog.csdn.net/weixin_50002038/article/details/130472426 2024/11/17 9:31:40

简介:

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，它提供了一个分布式环境中的高可用性、高性能、有序访问的数据存储，可以让分布式应用程序能够实现高效协调。提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户，让应用程序开发人员可以专注于应用程序的业务逻辑而不必关心协调任务的具体细节。ZooKeeper包含一个简单的原语集，提供Java和C的接口。ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在$zookeeper_home\src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。

ZooKeeper的优点包括：

高可靠性：ZooKeeper是一个高可靠的分布式协调服务，可以保证数据的一致性和完整性。
可扩展性：ZooKeeper支持动态扩展和缩减，可以根据需求调整资源的分配。
易用性：ZooKeeper提供了简单的原语集，使得开发者可以快速实现分布式应用。
安全性：ZooKeeper使用SSL加密通信，保证数据传输的安全性。

ZooKeeper是一个强大且灵活的分布式协调服务，适用于大规模分布式系统的场景。

下载路径

Index of /apache/zookeeper/zookeeper-3.7.1

注意: 3.5.5开始的版本要下载尾部有bin 别问为什么会报错

3.5.5开始，带有bin名称的包才是我们想要的下载可以直接使用的，里面有编译后的二进制的包。之前版本tar.gz包里面是只是源码包，无法直接使用。

配置环境变量

检测是否在系统变量path中配置 %JAVA_HOME%\bin 如果没有新建配置一下

说明

当前是windows的一个伪集群，正常的生产环境中分别部署到每一台机器上，也不是windows而是容器或linux中。

为什么是集群不是单机当然是保证系统高可用了。开始吧.........

解压目录

打开conf中的zoo_sample.cfg，修改后另存为zoo.cfg ，原始(zoo_sample.cfg)文件不会被执行。

参数解析 zoo.cfg文件

1.tickTime：CS通信心跳时间Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。tickTime以毫秒为单位。tickTime=2000

2.initLimit：LF初始通信时限集群中的follower服务器(F)与leader服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量）。initLimit=5

3.syncLimit：LF同步通信时限集群中的follower服务器与leader服务器之间请求和应答之间能容忍的最多心跳数（tickTime的数量）。syncLimit=2

4.dataDir：数据文件目录Zookeeper保存数据的目录，默认情况下，Zookeeper将写数据的日志文件也保存在这个目录里。dataDir=/home/zookeeper/zookeeper/zkdata

5.clientPort：客户端连接端口客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。clientPort=2181

6.服务器名称与地址：集群信息（服务器编号，服务器地址，LF通信端口，选举端口）规则如下:集群分布模式，server.id（数字）=ip：集群交互端口：选举leader端口
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

修改配置

注意: 下面路径单斜 " \ " 会当做是转义符处理 " \\ " 斜杠可以解决。(单机没问题如果是集群必报错)

#数据文件目录
dataDir=D:\work\zookeeperColony\apache-zookeeper-3.7.1-bin-server1\data
#日志文件目录
dataLogDir=D:\work\zookeeperColony\apache-zookeeper-3.7.1-bin-server1\logs#伪集群分布模式，server.id(注意是数字)=ip：集群交互端口：选举leader端口
server.1=localhost:2287:3387
server.2=localhost:2288:3388
server.3=localhost:2289:3389

在server1、 server2、 server3、分别创建 data 文件夹，data中创建myid文件（注意：不需要任何后缀），myid文件内容分别为1、2、3（对应的各server.id）。

注意: 集群启动时要检查是否有该文件，如果没有话，会报错！

启动闪退

如果启动闪退你可以编译 bin 下的 zkServer.cmd 添加pause 可以更清楚看清错误

启动实例

三个实例都配置完成后启动 bin 下的 zkServer.cmd 报错了

单机可以正常启动，集群就报错。

原因: 集群查找myid文件就嗝屁……是把"\"当做是转义符处理，所以路径错误，找不到myid文件从而启动失败，修改该路径后重新启动一切正常(改为双斜杠\\)

修改路径: dataDir=D:\\work\\zookeeperColony\\apache-zookeeper-3.7.1-bin-server1\\data

dataLogDir=D:\\work\\zookeeperColony\\apache-zookeeper-3.7.1-bin-server1\\logs

启动 server1 server2 server3 (注意: 在启动第一台服务会一直跳出错误信息，这是因为选举策略不用管) 机器数量启动过半了才能选出Leader

server1

server2

注意: 我在启动server3 这台服务的时候由于我的端口被占用我在server1 server2 server3 中分别对zoo.cfg 中的 server.3=localhost:2289:3389 改为 2286 :2286 方可正常。

server3

通过 cmd 命令行查看是否启动正常命令:jps

通过控制台看看不是一台LEADING 两台FOLLOWING

server1 是FOLLOWING

server2 是LEADING

server3 是FOLLOWING

总之，集群中id小的机器会向比自己id大的机器投票如果现在把server2 Leader 关闭 xunh server3 会接任 Leader职务可以自己试一下。

脚本一次性启动三台

一台一台启动太麻烦，创建文件 zookeeperstart.bat内容如下

Zookeeper 选举策略

领导者选举（Leader Election）：在ZooKeeper集群中，有一个主节点（Master），负责协调整个集群的运行。主节点会选举一个领导者（Leader），作为自己的代理人，负责处理集群中的事务和任务。当一个新的客户端连接到ZooKeeper集群时，它会尝试与主节点建立连接。如果连接成功，则客户端会发送一个请求，请求成为新的领导者。如果主节点已经选举出了一个领导者，则客户端会等待，直到领导者就职。如果领导者还未就职，则客户端会一直等待，直到领导者选举完成。
配置管理选举（Configuration Management Election）：在ZooKeeper集群中，可能会存在多个客户端同时连接到集群，需要共享一些配置信息。为了保证这些配置信息的一致性和可靠性，ZooKeeper集群会采用配置管理选举（Configuration Management Election）策略。在这种策略下，当一个客户端连接到ZooKeeper集群时，它会尝试与主节点建立连接。如果连接成功，则客户端会发送一个请求，请求成为新的领导者。如果主节点已经选举出了一个领导者，则客户端会等待，直到领导者就职。如果领导者还未就职，则客户端会一直等待，直到领导者选举完成。
多数选举（Majority Election）：在ZooKeeper集群中，如果多个客户端同时发送请求，想要成为新的领导者，则它们会根据一定的规则来竞争。具体来说，这些规则可能包括：时间戳、先到先得（Round Robin）等。在这种策略下，多个客户端会根据自己的请求时间戳来排序，最早请求的客户端会成为新的领导者。如果两个或多个客户端的请求时间戳相同，则ZooKeeper会采用“多数选举”策略，选举出一个领导者。
独裁选举（Throne Election）：在ZooKeeper集群中，只有一个客户端可以成为新的领导者。这种策略类似于“领导者选举”策略，但是当一个客户端成为领导者时，它可以完全控制整个ZooKeeper集群，包括资源分配、事务处理等。这种策略通常不推荐使用，因为它可能导致集群的不稳定和不可预测性。

总结: ZooKeeper的选举策略取决于具体的应用场景和需求。在选择选举策略时，需要考虑性能、可靠性、安全性等因素。不同的策略会对ZooKeeper集群的运行产生不同的影响，需要根据实际情况进行选择。

Zookeeper ZAB协议

Zookeeper的ZAB协议是一种分布式一致性协议，用于确保在分布式环境下多个Zookeeper实例之间的数据一致性。它主要包括原子广播和崩溃恢复两个功能。

原子广播：

ZAB协议通过原子广播机制来确保分布式环境下多个Zookeeper实例之间的数据一致性。具体来说，当一个Zookeeper实例（主节点）需要向其他Zookeeper实例（从节点）广播数据时，主节点会将数据以原子的方式广播到所有从节点。这样，所有从节点都能够同步数据，从而确保整个集群中的数据一致性。

崩溃恢复：

当主节点崩溃时，ZAB协议会自动触发崩溃恢复机制。在这种情况下，崩溃的主节点会将其数据复制到备用节点上，并重新选举一个新的主节点。这样，即使主节点崩溃，整个集群仍然能够保持数据一致性。

总结: ZAB协议通过原子广播和崩溃恢复两个机制来确保Zookeeper集群中的数据一致性和可靠性。这使得Zookeeper成为分布式环境下进行高可用性和可靠性部署的理想选择。

Zookeeper 数据模型

ZooKeeper 是一个树形目录服务,其数据模型和Unix的文件系统目录树很类似，拥有一个层次化结构。
这里面的每一个节点都被称为: ZNode，每个节点上都会保存自己的数据和节点信息。
节点可以拥有子节点，同时也允许少量(1MB)数据存储在该节点之下

ZooKeeper的数据模型主要包含以下几个部分：

1、Name Space：ZooKeeper的数据模型类似于文件系统，使用 Name Space 来表示不同的数据对象。每个 Name Space 由一组唯一的标识符组成，称为节点（Node）。节点是 ZooKeeper 树中的基本单位，每个节点都有一个唯一的数字标识符。

2、Data Store：ZooKeeper 的数据存储在称为数据存储（Data Store）的节点中。每个数据存储节点都是一个文件，用于存储数据和元数据信息。

数据存储节点通常包含以下几个部分：

a. Data：数据存储节点中存储的是数据对象，例如文件、哈希表等。

b. MetaData：数据存储节点中还包含元数据信息，例如文件权限、所有者等。

c. ACL：ACL（访问控制列表）是一个用于定义节点间权限的数据结构。在 ZooKeeper 中，ACL 用于限制不同用户对节点的访问权限。
3、Node：ZooKeeper 树中的每个节点都由一个唯一的数字标识符组成，称为 Znode。Znode 是 ZooKeeper 树中的基本单位，代表着一个数据对象。

Znode 包含以下几个部分：

a. Stat：Znode 包含一个元数据信息，例如文件大小、修改时间等。

b. Data：Znode 存储着实际的数据对象。

c. Children：Znode 可以包含子节点，用于存储子数据对象或者其他 Znode。
4、 Zxid：Zxid 是一个全局唯一的标识符，用于确保每个事件在 ZooKeeper 树中的唯一性。Zxid 用于生成序列号，以便在事件通知和领导者选举过程中使用。

注: ZooKeeper的数据模型通过使用树形结构来组织数据，每个节点代表着一个数据对象，节点之间通过父子关系相互关联。这种结构保证了在分布式系统中所有数据的一致性和事件驱动的行为。

Zookeeper 节点四大类

临时节点：临时节点用于存储会话数据和事件，它们的生命周期与客户端会话绑定，一旦会话结束，这些节点将被自动删除。
持久节点：持久节点用于存储长期数据，例如状态信息、配置数据等。它们具有永久性，即使客户端会话断开，节点也会保留在 ZooKeeper 中。
顺序节点：顺序节点是根据预定顺序链接在一起的一组节点。它们用于实现分布式锁机制，当多个客户端请求同一个资源时，只有一个客户端可以获得锁并进行操作，其他客户端需要等待。
临时顺序节点：临时顺序节点是一种特殊类型的顺序节点，它们具有临时性和顺序性。临时顺序节点在满足特定条件时会转换为永久顺序节点，而在此期间它们可以被多个客户端共享。

Zookeeper 节点类型

持久节点（Persistent）：是Zookeeper中最常见的节点类型，它们在服务器上永久存在，直到被删除。这些节点用于存储数据和元信息，如成员关系、权限等。
临时节点（Ephemeral）：临时节点在服务器上存活的时间通常较短，它们用于创建临时数据和关系，例如订阅关系或发布/订阅关系。临时节点在建立后会被快速删除，以确保节点状态的可恢复性。
顺序节点（Sequential）：顺序节点是按照顺序创建的，它们用于在分布式环境中存储有序数据。顺序节点在建立后会按照预定的顺序被引用和访问。
分区节点（Partition）：分区节点用于将Zookeeper实例分成多个子集，每个子集可以独立管理。分区节点可以提高Zookeeper的可扩展性和容错性。
聚合节点（Aggregating）：聚合节点用于将多个Zookeeper实例的数据合并为一个大的聚合实例。聚合节点可以减少网络带宽的使用，提高数据传输速度。
持久顺序节点（Persistent Sequential）：持久顺序节点是介于持久节点和顺序节点之间的一种节点类型。它们在建立后会保留数据和元信息，直到被删除。这些节点通常用于存储有序数据，如任务或事件。
容器节点（Container）：容器节点是专门用于存储和管理共享资源的节点。它们可以跨多个Zookeeper实例存在，提高了资源的可共享性和管理效率。
同步节点（Synchronous）：同步节点在创建时就会一直保持同步状态，它们不能接收新的事务，只能接收崩溃重试事务。同步节点主要用于测试和开发环境下的事务处理。
异步节点（Asynchronous）：异步节点在创建时不会保持同步状态，它们可以接收新的事务并进行处理，但是事务的提交和回滚是异步的。异步节点主要用于实时性要求较高的场景，如视频流或实时通信应用。

以上是ZK的一些常见节点类型，不同的节点类型在ZK中具有不同的含义和用途。

Zookeeper watch 监听

ZooKeeper 的 watch 监听是一种机制，用于监视分布式系统中的变化。ZooKeeper 的 watch 监听机制可以帮助应用程序实现以下功能：

心跳检测：ZooKeeper 监视客户端连接状态并自动进行心跳检测。如果客户端断开连接，ZooKeeper 将发送一个心跳包以确保客户端仍在运行。
变化检测：ZooKeeper 支持多种变化检测方式，例如读取、写入、删除等操作。当ZooKeeper 检测到分布式系统中发生变化时，它将通知相关客户端。
自动修复：ZooKeeper 具有自动修复机制，可以在分布式系统中的节点出现故障时自动进行故障转移。这样，ZooKeeper 可以确保分布式系统的高可用性和可靠性。

ZooKeeper 的 watch 监听机制通常由以下组件组成：

Watcher：Watcher 是 ZooKeeper 的核心组件，用于监视分布式系统中的变化。它负责监视节点的状态、事件和变化，并将这些信息通知给相关客户端。
Event：Event 是 ZooKeeper 中的一种事件类型，用于描述分布式系统中的变化。Event 包含有关变化的详细信息，例如读取、写入、删除等操作。
WatchManager：WatchManager 是 ZooKeeper 的一个组件，用于管理 watch 监听。它负责创建、删除和重启 watcher，以及协调 watcher 之间的通信。

ZooKeeper 的 watch 监听机制可以帮助应用程序实现分布式系统的监视、心跳检测、变化检测和自动修复等功能。

Zookeeper 集群中的角色

Leader：是Zookeeper集群工作的核心，也是事务性请求（写操作）的唯一调度和处理者，它保证集群事务处理的顺序性，同时负责进行投票的发起和决议。
Follower：是Zookeeper集群中的另一个重要角色，它负责处理客户端非事务（读操作）请求，转发事务请求给Leader；参与集群Leader选举投票。
Observer：对于非事务请求可以独立处理（读操作），对于事务性请求会转发给Leader处理，但不参与任何形式的投票。
Secret Manager：负责群成员的加入、删除、退出操作，管理共享数据的一致性。
Graceful exit：负责组织有序地退出。

导图

以上是Zookeeper集群中的主要角色，它们各司其职，共同保证Zookeeper集群的正常运行。