点一下关注吧！！！非常感谢！！持续更新！！！

🚀 AI 篇持续更新中！（长期更新）

目前 2025 年 06 月 16 日更新到：AI 炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究，持续打造实用 AI 工具指南！📐🤖

💻 Java 篇正式开启！（300 篇）

目前 2025 年 06 月 28 日更新到：Java-58 深入浅出 分布式服务 ACID 三阶段提交 3PC 对比 2PCMyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！目前 2025 年 06 月 13 日更新到：大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解

章节内容

上节我们顺利完成了：

• Sqoop CDC ChangeDataCapture 差量数据捕获

• CDC 的几种类型 侵入式和非侵入式

• Sqoop 数据差量更新导入 从 MySQL 到 Hive

Sqoop 目前就算告一段落了，接下来我们将开始 ZooKeeper！！！

背景介绍

这里是三台公网云服务器，每台 2C4G，搭建一个 Hadoop 的学习环境，供我学习。

• 2C4G 编号 h121

• 2C4G 编号 h122

• 2C2G 编号 h123

ZooKeeper 简介

核心特性

1. 分布式一致性保证：

2. 提供顺序一致性（所有更新请求按顺序执行）

3. 原子性（更新要么成功要么失败）

4. 单一系统镜像（无论连接到哪个服务器，客户端看到的数据视图都是一致的）

5. 可靠性（一旦更新被应用，将保持到被下一次更新覆盖）

6. 及时性（客户端在一定时间内能看到最新的数据）

7. 数据模型：

8. 本质上是一个分布式的小文件存储系统，采用类似 Unix 文件系统的树形层次结构（称为 ZNode Tree）

9. 每个节点（ZNode）可以存储少量数据（默认上限 1MB）

10. 节点分为持久节点（PERSISTENT）和临时节点（EPHEMERAL），后者在会话结束后自动删除

11. 监控机制（Watcher）：

12. 客户端可以注册监听特定节点的变化

13. 当节点数据变更或子节点列表变化时会触发通知

14. 采用一次触发机制，收到通知后需要重新注册

典型应用场景

1. 统一命名服务：

2. 如 Dubbo 服务注册中心，服务提供者将服务地址注册到 ZooKeeper

3. 消费者从 ZooKeeper 获取可用的服务列表

4. 示例：/dubbo/com.example.Service/providers 目录下存储服务提供者 URL

5. 分布式配置管理：

6. 如 Solr 集群配置同步，所有节点监听配置节点

7. 配置变更时，管理员更新 ZooKeeper 上的配置数据

8. 各节点收到变更通知后自动获取新配置

9. 示例：/solr/configs/mycore 目录存储核心配置

10. 分布式消息队列：

11. 实现发布/订阅模式（Pub/Sub）

12. 生产者创建顺序节点作为消息

13. 消费者监听父节点获取新消息

14. 示例：/queue/msg-0000000001，/queue/msg-0000000002

15. 分布式锁：

16. 实现互斥锁：多个客户端竞争创建同一个临时节点，成功创建的获得锁

17. 实现共享锁：通过节点顺序特性实现读写锁

18. 锁释放：会话结束自动删除临时节点或主动删除

19. 集群管理：

20. 监控集群节点存活状态（通过临时节点）

21. 选举主节点（通过节点序号最小的成为 Master）

22. 示例：/cluster/node1（临时节点）自动消失表示节点下线

工作原理

ZooKeeper 集群是一个高可用的分布式协调服务，其核心架构和运行机制如下：

1. 集群组成与节点数量

• 典型部署包含 3 个、5 个或 7 个服务器节点（必须为奇数）

• 奇数数量便于选举时形成多数派（quorum），如：

• 3 节点集群可容忍 1 个节点故障（需要 2 个节点存活）

• 5 节点集群可容忍 2 个节点故障（需要 3 个节点存活）

• 每个节点都存储完整的数据副本

2. 一致性协议

• 采用 ZAB（ZooKeeper Atomic Broadcast）协议，该协议包含两个主要阶段：a) 选举阶段：当 Leader 失效时，剩余节点通过投票选出新 Leaderb) 广播阶段：Leader 将事务请求以提案形式广播给所有 Follower

• 需要获得多数节点（N/2+1）的 ACK 才能提交事务

• 所有写操作都通过 Leader 处理，读操作可由任意节点响应

3. 请求处理流程

• 客户端可以连接到集群中的任意节点

• 对于写请求：

• 接收节点会将请求转发给 Leader

• Leader 生成事务提案并广播

• 获得多数确认后提交并响应客户端

• 对于读请求：

• 可直接由接收节点本地响应（可能读到稍旧数据）

• 可选 sync 操作确保读取最新数据

4. 容错机制

• 故障检测通过心跳机制实现

• Leader 失效时会自动触发新的选举

• 集群持续服务需要保持多数节点存活

• 数据持久化到磁盘，重启后自动恢复

5. 典型应用场景

• 分布式锁服务

• 配置管理中心

• 命名服务

• 集群成员管理

• 选主服务

在实际生产环境中，通常会将 ZooKeeper 节点部署在不同的物理服务器或可用区，以避免单点故障。同时建议配置监控系统来跟踪节点健康状态和性能指标。

架构组成

我们也将进行集群的搭建集群模式

• h121 节点

• h122 节点

• h123 节点

• 

Leader

• ZooKeeper 集群工作的核心角色

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

• 事务请求（写操作）的唯一调度和处理者，保证集群事务处理的顺序性，对于 create，setData、delete 等有写操作的请求，则需要统一转发给 leader 处理。

Follower

• 处理客户端非事务（读操作）请求

• 转发事务请求给 Leader

• 参与集群 Leader 选择股票 2n-1 台可新增观察者角色

Observer

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

• 不会参与任何形式的投票只提供非事务服务，通常用于不影响集群事务处理能力的前提下提升集群的非事务处理能力。增加了集群增加并发的读请求。

项目简介

Zookeeper 集群架构详解

Zookeeper 采用主从（Leader-Follower）架构的集群模式，具体工作方式如下：

集群组成结构

• 由 1 个 Leader 节点 和 多个 Follower 节点 共同组成集群

• 典型部署建议 3 个或 5 个节点（奇数个），这样可以保证选举时能明确产生多数派

节点角色分工

Leader 节点

• 负责处理所有 写请求 的事务操作

• 管理 投票过程，协调集群决策

• 发起并执行 状态更新 操作

• 将事务日志（Zxid）同步给 Follower 节点

• 示例：当客户端发起创建节点的请求时，只有 Leader 能处理这个写操作

Follower 节点

• 接受客户端读请求 并直接返回结果（提供高可用读取）

• 在 Leader 选举 过程中参与投票

• 同步 Leader 的数据变更，保持数据一致性

• 可以处理 非事务性写请求（如 exists/getData 等）

• 当 Leader 失效时，Follower 会参与新 Leader 的选举

集群容错机制

• 过半存活原则：只要集群中超过半数的节点存活（如 3 节点集群中至少 2 个存活），Zookeeper 就能继续正常工作

• 这种设计保证了：

• 5 节点集群可容忍 2 个节点故障

• 3 节点集群可容忍 1 个节点故障

• 7 节点集群可容忍 3 个节点故障

数据一致性保证

• 全局数据一致：

• 每个 Server 节点都保存 完整的数据副本

• 无论客户端连接到哪个节点（Leader 或任意 Follower），看到的数据都是一致的

• 实现方式：使用 ZAB 协议（Zookeeper Atomic Broadcast）保证数据同步

• 顺序一致性：

• 所有更新请求按照 全局严格顺序 执行

• 每个更新操作都会被分配一个全局唯一的 zxid（Zookeeper Transaction ID）

• 示例：如果操作 A 的 zxid 是 0x100001，操作 B 是 0x100002，那么 A 一定在 B 之前执行

• 原子性保证：

• 数据更新具有原子性特征

• 一次数据更新要么 完全成功（被集群多数节点确认）

• 要么 完全失败（未被多数节点确认）

• 不会出现部分成功的情况

实际应用场景

这种架构设计使得 Zookeeper 特别适合作为：

• 分布式系统的配置中心

• 命名服务

• 分布式锁服务

• 集群管理

• 选主服务

例如在 Kafka 集群中，就使用 Zookeeper 来存储和协调 broker、topic 和 partition 的元数据信息。

搭建方式

搭建有分为几种方式：

• 单机模式：ZooKeeper 只运行在一台服务器上，适合测试环境。

• 伪集群模式：就是在一台机器上运行多个 ZooKeeper

• 集群模式：生产环境，多台机器

下载服务

http://zookeeper.apache.org/releases.html

这里我选择：3.8.4 版本进行安装测试，这是最新的稳定版本。下载地址如下，你可以使用 wget 进行下载

https://dlcdn.apache.org/zookeeper/zookeeper-3.8.4/apache-zookeeper-3.8.4-bin.tar.gz

下载完成至服务器节点

解压安装

cd /opt/software/tar -zxvf apache-zookeeper-3.8.4-bin.tar.gz -C ../servers/

文件夹配置

数据文件夹

cd /opt/servers/apache-zookeeper-3.8.4-binmkdir -p /opt/servers/apache-zookeeper-3.8.4-bin/data

日志文件夹

cd /opt/servers/apache-zookeeper-3.8.4-binmkdir -p /opt/servers/apache-zookeeper-3.8.4-bin/logs

配置文件

cd /opt/servers/apache-zookeeper-3.8.4-bin/confmv zoo_sample.cfg zoo.cfgvim zoo.cfg

修改为如下的内容：

# 数据和日志文件夹dataDir=/opt/servers/apache-zookeeper-3.8.4-bin/datadataLogDir=/opt/servers/apache-zookeeper-3.8.4-bin/logs
# 集群地址server.1=h121.wzk.icu:2888:3888server.2=h122.wzk.icu:2888:3888server.3=h123.wzk.icu:2888:3888
# 清理日志 1小时autopurge.purgeInterval=1

修改结果如下图：

myid 配置

我们需要在数据目录下新建一个叫 myid 文件夹，内容为 1，后续集群要用到：

cd /opt/servers/apache-zookeeper-3.8.4-bin/dataecho 1 > myid

至此，我们 ZooKeeper 的单机安装完成！！！