大数据-26 ZooKeeper 分布式协调框架 简介与配置 Leader Follower Observer

武子康
148 阅读9分钟

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

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

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

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

目前2025年06月28日更新到： Java-58 深入浅出 分布式服务 ACID 三阶段提交3PC 对比2PC MyBatis 已完结，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. 数据模型：

    • 本质上是一个分布式的小文件存储系统，采用类似Unix文件系统的树形层次结构（称为ZNode Tree）
    • 每个节点（ZNode）可以存储少量数据（默认上限1MB）
    • 节点分为持久节点（PERSISTENT）和临时节点（EPHEMERAL），后者在会话结束后自动删除

  3. 监控机制（Watcher）：

    • 客户端可以注册监听特定节点的变化
    • 当节点数据变更或子节点列表变化时会触发通知
    • 采用一次触发机制，收到通知后需要重新注册

典型应用场景

  1. 统一命名服务：

    • 如Dubbo服务注册中心，服务提供者将服务地址注册到ZooKeeper
    • 消费者从ZooKeeper获取可用的服务列表
    • 示例：/dubbo/com.example.Service/providers目录下存储服务提供者URL

  2. 分布式配置管理：

    • 如Solr集群配置同步，所有节点监听配置节点
    • 配置变更时，管理员更新ZooKeeper上的配置数据
    • 各节点收到变更通知后自动获取新配置
    • 示例：/solr/configs/mycore目录存储核心配置

  3. 分布式消息队列：

    • 实现发布/订阅模式（Pub/Sub）
    • 生产者创建顺序节点作为消息
    • 消费者监听父节点获取新消息
    • 示例：/queue/msg-0000000001，/queue/msg-0000000002

  4. 分布式锁：

    • 实现互斥锁：多个客户端竞争创建同一个临时节点，成功创建的获得锁
    • 实现共享锁：通过节点顺序特性实现读写锁
    • 锁释放：会话结束自动删除临时节点或主动删除

  5. 集群管理：

    • 监控集群节点存活状态（通过临时节点）
    • 选举主节点（通过节点序号最小的成为Master）
    • 示例：/cluster/node1（临时节点）自动消失表示节点下线

工作原理

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

  1. 集群组成与节点数量
  • 典型部署包含3个、5个或7个服务器节点（必须为奇数）
  • 奇数数量便于选举时形成多数派（quorum），如：
    • 3节点集群可容忍1个节点故障（需要2个节点存活）
    • 5节点集群可容忍2个节点故障（需要3个节点存活）
  • 每个节点都存储完整的数据副本
  1. 一致性协议
  • 采用ZAB（ZooKeeper Atomic Broadcast）协议，该协议包含两个主要阶段： a) 选举阶段：当Leader失效时，剩余节点通过投票选出新Leader b) 广播阶段：Leader将事务请求以提案形式广播给所有Follower
  • 需要获得多数节点（N/2+1）的ACK才能提交事务
  • 所有写操作都通过Leader处理，读操作可由任意节点响应
  1. 请求处理流程
  • 客户端可以连接到集群中的任意节点
  • 对于写请求：
    • 接收节点会将请求转发给Leader
    • Leader生成事务提案并广播
    • 获得多数确认后提交并响应客户端
  • 对于读请求：
    • 可直接由接收节点本地响应（可能读到稍旧数据）
    • 可选sync操作确保读取最新数据
  1. 容错机制
  • 故障检测通过心跳机制实现
  • Leader失效时会自动触发新的选举
  • 集群持续服务需要保持多数节点存活
  • 数据持久化到磁盘，重启后自动恢复
  1. 典型应用场景
  • 分布式锁服务
  • 配置管理中心
  • 命名服务
  • 集群成员管理
  • 选主服务

在实际生产环境中，通常会将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-bin
mkdir -p /opt/servers/apache-zookeeper-3.8.4-bin/data

日志文件夹

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

配置文件

在这里插入图片描述

cd /opt/servers/apache-zookeeper-3.8.4-bin/conf
mv zoo_sample.cfg zoo.cfg
vim zoo.cfg

修改为如下的内容：

# 数据和日志文件夹
dataDir=/opt/servers/apache-zookeeper-3.8.4-bin/data
dataLogDir=/opt/servers/apache-zookeeper-3.8.4-bin/logs

# 集群地址
server.1=h121.wzk.icu:2888:3888
server.2=h122.wzk.icu:2888:3888
server.3=h123.wzk.icu:2888:3888

# 清理日志 1小时
autopurge.purgeInterval=1

修改结果如下图： 在这里插入图片描述

myid配置

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

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

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

avatar
文章
阅读
粉丝