zookeeper 学习

Zookeeper 简介

github：https://github.com/apache/zookeeper

官网：https://zookeeper.apache.org/

什么是 Zookeeper

Zookeeper 是一个开源的分布式协调服务，用于管理分布式应用程序的配置、命名服务、分布式同步和组服务。其核心是通过高效的一致性协议（如 Zab 协议）保证分布式系统的数据一致性，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应。。

作用

• 配置管理：集中存储和管理分布式系统的配置信息（如数据库连接参数）。
• 命名服务：提供全局唯一的路径标识符（如服务注册与发现）。
• 分布式锁：实现跨进程的互斥访问，避免资源竞争。
• 集群管理：监控节点状态，实现故障检测和主节点选举。
• 数据同步：确保多个节点间的数据一致性（如 Kafka 的 Partition 负载均衡）。

特点

• 高可用性：基于多节点集群，部分节点故障不影响整体服务。
• 顺序一致性：所有操作按全局顺序执行（通过递增的 zxid 实现）。
• 实时性：客户端在一定时间内能读取最新数据。
• 轻量级：数据模型简单（类似文件系统），适合高频读写场景。
• 集群中只要有半数以上节点存活，Zookeeper 集群就能正常服务。所以 Zookeeper 适合安装奇数台服务器。

架构

ZooKeeper 集群包含以下角色：

1. Leader：负责处理写请求，发起提案并协调数据同步。
2. Follower：处理读请求，参与 Leader 选举和提案投票。
3. Observer：仅处理读请求，不参与投票（用于扩展读性能）。

数据模型：

• 采用树形结构的 ZNode（类似文件系统的目录/文件）。
• 每个 ZNode 存储数据（上限 1MB），并可通过路径唯一标识（如 /services/db）。
• 支持临时节点（会话结束后自动删除）和顺序节点（路径末尾追加递增序号）。

核心原理

• Zab 协议：
  1. 崩溃恢复模式：Leader 选举（基于 zxid 最大原则）和数据同步。
  2. 消息广播模式：Leader 将写请求广播给所有节点，收到多数确认后提交。
• 会话机制：客户端与 ZooKeeper 建立会话（通过心跳保持活性），临时节点生命周期与会话绑定。
• Watch 机制：客户端可监听 ZNode 变化（如节点删除或数据更新），触发事件通知。

zookeeper 数据结构

数据模型

ZooKeeper 采用树形结构（类似文件系统）存储数据，称为 ZNode 树。每个节点（ZNode）具有以下特性：

• 路径唯一性：通过 / 分隔的层级路径唯一标识（如 /services/db/master）。
• 数据存储：每个 ZNode 可存储不超过 1MB 的数据（通常用于存储配置、状态等元数据）。
• 版本控制：每个 ZNode 维护一个递增的版本号（version），用于实现原子操作（如 CAS）。

示例 ZNode 树结构：
/
├── /config
│   └── database_url (存储数据库连接信息)
├── /services
│   ├── service1 (临时节点，表示在线服务实例)
│   └── service2 (临时节点)
└── /locks
    └── lock-00000001 (顺序节点，用于分布式锁)

节点类型

ZooKeeper 支持多种 ZNode 类型，通过组合实现不同功能：

类型	特性	应用场景
持久节点	节点在客户端断开后仍存在	存储长期配置（如 /config）
临时节点	节点生命周期与客户端会话绑定，会话结束自动删除	服务实例注册（如 /services）
顺序节点	节点路径末尾自动追加全局唯一递增序号（如 /locks/lock-00000001）	分布式锁、队列管理
持久顺序节点	持久节点 + 顺序特性	需持久化且有序的场景
临时顺序节点	临时节点 + 顺序特性	临时有序资源分配

zookeeper 统一配置管理

核心实现机制

1. 树形节点存储

   Zookeeper 采用树形结构（ZNode 树）存储配置数据，每个节点路径如 /config/database/config/database，节点可存储配置内容（如 JSON/XML 格式）。节点类型分为持久节点（PERSISTENT）和临时节点（EPHEMERAL），配置管理通常使用持久节点。

2. Watcher 监听机制

   客户端通过注册 Watcher 监听特定节点（如getData("/config", true)）。当节点数据变更时，Zookeeper 主动推送事件通知客户端。Watcher 为一次性触发，需在回调函数中重新注册以实现持续监听。

3. 版本控制（Versioning）

   每个节点包含版本号 version，更新操作需验证版本号：

   ​ setData(path,data,version_current)

   若 version_current 与服务端不一致，操作失败，防止并发冲突。

配置更新流程

1. 管理员更新配置
   • 通过 Zookeeper 客户端执行 setData("/config", new_data)
   • 节点版本号 version 自动递增
2. 客户端响应变更
   • 客户端收到Watcher事件后，主动调用getData("/config")拉取最新数据
   • 触发预定义的回调函数（如刷新本地缓存、重启服务）

zookeeper 统一集群配置

1. 集群数据一致性保障

   Zookeeper 通过 ZAB 协议实现集群节点间的数据同步。当配置变更时，Leader 节点会将操作序列化为事务，通过两阶段提交（Phase 1：Proposal，Phase 2：Commit）广播给所有 Follower 节点，确保所有节点数据最终一致。

2. 树形节点存储结构

   集群中所有节点共享同一个 ZNode 树结构，例如：

   /cluster-config
       /database
           /master (存储主库配置)
           /slave1 (存储从库配置)
       /service
           /api-timeout (服务超时参数)
   

   每个节点最大存储数据量为1MB，适合存储小规模配置信息。

3. 分布式 Watcher 机制

   客户端在任意集群节点注册 Watcher 后，事件通知由服务端集群统一管理。例如，当节点 /cluster-config/database 数据变更时，所有订阅该节点的客户端都会收到跨集群的事件通知。

zookeeper 配置文件参数

基础参数配置

1. tickTime
   • 作用：Zookeeper 的时间基准单位（毫秒），用于计算心跳超时、会话超时等时间参数。
   • 默认值：tickTime=2000
   • 计算公式：会话超时时间 = tickTime×2（最小值）至 tickTime×20（最大值）
2. initLimit
   • 作用：集群中 Follower 节点与 Leader 节点建立初始连接的最大容忍心跳次数。
   • 计算公式：超时时间 = initLimit × tickTime，例如：initLimit=5 时，超时时间为 5×2000=10000ms
3. syncLimit
   • 作用：Follower 与 Leader 数据同步的最大等待心跳次数。
   • 典型值：syncLimit=2（对应 2×2000=4000ms 超时）

核心路径配置

1. dataDir
   • 作用：存储内存快照（snapshot）的目录
   • 注意事项：
     • 生产环境需避免使用 /tmp 目录（易被系统清理）
     • 示例：dataDir=/var/lib/zookeeper/data
2. dataLogDir（可选）
   • 作用：单独指定事务日志（WAL）存储路径
   • 优势：将数据与日志分离可提升 IO 性能
   • 示例：dataLogDir=/var/lib/zookeeper/log

网络与集群配置

1. clientPort

   • 作用：客户端连接端口
   • 默认值：clientPort=21813

2. server.id

   • 集群节点声明格式：

     server.1=node1:2888:3888
     server.2=node2:2888:3888
     server.3=node3:2888:3888
     

   • 端口说明：

     • 2888：Leader-Follower 数据同步端口
     • 3888：选举通信端口

高级调优参数

1. autopurge.snapRetainCount
   • 作用：保留最近 N 个快照文件
   • 推荐值：autopurge.snapRetainCount=3
2. autopurge.purgeInterval
   • 作用：清理历史数据的周期（小时）
   • 示例：autopurge.purgeInterval=24

配置示例

# 基础配置
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/data/zookeeper
clientPort=2181

# 集群节点配置
server.1=192.168.1.101:2888:3888
server.2=192.168.1.102:2888:3888
server.3=192.168.1.103:2888:3888

# 日志管理
autopurge.purgeInterval=24
autopurge.snapRetainCount=5

zookeeper 选举机制

首次选举流程（集群初始化）

1. 状态初始化

   所有节点启动时均为 LOOKING 状态，触发首次选举。每个节点先投自己一票，包含其 ZXID 和 SID。

2. 选票交换规则

   • 优先级排序：优先比较 ZXID（事务ID），数值越大表示数据越新；若 ZXID 相同，则选择 SID（服务器ID）较大的节点。
   • 过半原则：候选节点需获得超过半数投票才能成为 Leader。

3. 选举过程示例

   假设集群有3个节点（SID = 1、2、3，初始 ZXID = 0）：

   • 节点1投自己，广播选票 (ZXID = 0, SID = 1)；
   • 节点2投自己，广播选票 (ZXID = 0, SID = 2)；
   • 节点3投自己，广播选票 (ZXID = 0, SID = 3)；
   • 所有节点收到其他选票后，发现 SID = 3 最大，最终节点3以3票当选 Leader，其余节点转为 FOLLOWING。

非首次选举流程（Leader 故障）

1. 触发条件

   当 Leader 节点宕机或网络中断时，剩余节点重新进入 LOOKING 状态，触发新一轮选举。

2. 选票比较逻辑

   • 优先比较 ZXID 的 epoch（任期），若 epoch 相同则比较 counter（事务计数器）；
   • 若 ZXID 完全相同，再比较 SID。

3. 动态改票机制

   节点在收到更高优先级的投票时（如更大的 ZXID 或 SID），会更新自己的投票并广播给其他节点，加速达成共识。

4. 示例场景

   假设原 Leader（SID = 3，ZXID = 0x1001）宕机，剩余节点 ZXID 分别为：

   • 节点1：ZXID = 0x1001（与旧 Leader 同步）
   • 节点2：ZXID = 0x1002（处理过新事务）
   • 节点2因 ZXID 更大，优先成为新 Leader。

关键差异对比

维度	首次选举	非首次选举
触发条件	集群初始化	Leader 故障或失联
ZXID 初始值	全为0	包含历史事务数据
选举复杂度	较高（需全员协商）	较低（已有数据参考）
改票频率	频繁（初始状态无优先级）	较少（已有明确优先级）

技术细节补充

• ZXID 结构：

  ZXID = epoch × 2³² + counter

  每次选举后 epoch 递增，确保旧 Leader 无法干扰新任期.

• 网络优化：采用 TCP 连接减少丢包，逻辑时钟（epoch）避免历史投票干扰。

zookeeper 节点类型

节点分类

zookeeper 的节点主要分为临时节点和持久节点。根据生命周期和顺序性可分为四类：

1. 持久节点
2. 持久顺序节点
3. 临时节点
4. 临时顺序节点

核心特性对比

类型	生命周期	顺序性	子节点限制	典型应用场景
持久节点	永久存在，需手动删除	无	允许创建子节点	存储配置信息、元数据
持久顺序节点	永久存在，需手动删除	有序	允许创建子节点	分布式任务队列、全局有序ID生成
临时节点	随会话结束自动删除	无	禁止创建子节点	心跳检测、服务注册
临时顺序节点	随会话结束自动删除	有序	禁止创建子节点	分布式锁、选举协调

详细说明

持久节点

• 生命周期：

  节点创建后永久存在于 ZooKeeper 中，除非显式调用 delete 删除。

• 特性：

  • 客户端断开连接后节点仍保留。
  • 支持创建子节点（例如在 /config 下创建 /config/database）

• 用途：

  存储需长期保存的数据，如系统配置、集群元数据。

持久顺序节点

• 顺序性：

  ZooKeeper 自动在节点名称后追加单调递增的10位数字序号（例如 /task/task-0000000001）。

• 用途：

  • 实现分布式队列（按序号处理任务）。
  • 生成全局唯一有序ID（如事务ID）。

临时节点

• 生命周期：

  节点的存在与客户端会话绑定。若客户端断开连接或会话超时，节点自动删除。

• 限制：

  临时节点不能创建子节点（例如在 /service 下创建 /service/node1 后，无法再创建 /service/node1/subnode）。

• 用途：

  • 服务注册与发现（服务下线后节点自动清除）
  • 心跳检测（通过节点存在性判断服务存活状态）

临时顺序节点

• 组合特性：

  同时具备临时节点的生命周期和顺序节点的序号特性。

• 用途：

  • 分布式锁：通过序号判断最小节点持有锁（如 /lock/lock-0000000001）
  • Leader 选举：序号最小的节点成为 Leader

技术实现验证

• 判断节点类型：

  通过 Curator 框架的 Stat 对象中的 ephemeralOwner 属性可区分节点类型。若 ephemeralOwner 值为0，则为持久节点；非0则为临时节点。

// 示例：使用Curator检查节点类型
Stat stat = curatorFramework.checkExists().forPath("/node");
if (stat.getEphemeralOwner() == 0) {
    System.out.println("持久节点");
} else {
    System.out.println("临时节点");
}

应用场景示例

1. 服务注册中心
   • 临时节点：服务实例注册临时节点，断连后自动注销。
   • 持久节点：存储服务路由策略等长期配置。
2. 分布式锁
   • 临时顺序节点：多个客户端竞争创建临时顺序节点，最小序号者获得锁。
3. 配置管理
   • 持久节点：存储数据库连接字符串等全局配置。

zookeeper 监听器

核心概念

Zookeeper 的监听器（Watcher）是一种事件驱动机制，允许客户端实时感知 ZNode 的状态变化。其核心特性包括：

1. 一次性触发：每个 Watcher 仅生效一次，触发后需重新注册。
2. 异步通知：事件通过异步队列传递，保证系统高吞吐。
3. 事件类型全覆盖：包括节点创建、删除、数据变更和子节点变化。

工作原理流程图

客户端注册Watcher

服务端记录监听关系

节点状态变化

服务端生成事件

客户端事件队列

回调处理process

重新注册Watcher

核心流程分步解析

注册监听器

• 触发方式：通过 exists、getData、getChildren 等 API 注册。
• 代码示例：

zk.getData("/sanguo", new Watcher() {
    @Override
    public void process(WatchedEvent event) {
        // 处理事件逻辑
    }
}, null);

此时服务端会记录客户端对 /sanguo 节点的监听关系。

事件触发与传递

• 服务端检测到节点变化时，生成对应事件类型：
  • 数据变更：EventType.NodeDataChanged
  • 节点删除：EventType.NodeDeleted
  • 子节点变化：EventType.NodeChildrenChanged
• 事件通过 TCP 连接异步发送到客户端的事件队列。

事件处理

客户端通过单线程从事件队列取出事件，调用 process() 方法：

public void process(WatchedEvent event) {
    System.out.println("检测到事件类型：" + event.getType());
    // 重新注册监听器以持续监听[^3]
    zk.getData(event.getPath(), this, null); 
}

此时原 Watcher 已失效，需在回调中重新注册才能继续监听

事件丢失防护

• 会话有效期内：即使客户端暂时断开连接，未处理事件仍会保留。
• 心跳机制：通过 sessionTimeout 参数（默认2倍 tickTime）维持长连接

关键技术特性

特性	说明	数学表达
一次性监听	每个 Watcher 仅触发一次，避免服务端状态维护压力	$W_{active}$ = ${\sum }_{i=1}^n$$W_i$
事件有序性	客户端保证事件处理的 FIFO 顺序	$E1\to E2\to E3$
轻量级通知	仅通知事件类型，不传递具体数据，需客户端主动查询	$Notification=(Type,Path)$

应用场景示例

1. 配置中心

   // 注册配置节点监听
   zk.getData("/config/database", watcher, null);
   

   当数据库配置变更时，立即触发应用配置刷新。

2. 分布式锁释放检测

   zk.exists("/lock/resource1", lockWatcher);
   

   当锁持有者会话断开时，临时节点删除触发锁释放通知

3. 服务发现

   监控/services子节点变化，实时更新服务实例列表。

zookeeper 写数据原理

Zookeeper 的写数据机制基于 ZAB（Zookeeper Atomic Broadcast）协议，确保分布式环境下数据的一致性。其核心流程如下：

写请求接收与转发

• 客户端向任意节点（Leader 或 Follower）发起写请求（如 setData）。
• 若接收节点是 Follower，会将请求转发给 Leader。

Leader 生成事务提案

• Leader 收到写请求后，生成一个全局唯一的 事务 ID（ZXID），并将操作封装为 事务提案。
• Leader 将提案通过 两阶段提交（2PC） 广播给所有 Follower。

提案广播与确认

• 阶段一（Proposal）：Leader 发送提案至所有 Follower，Follower 将提案写入本地日志并返回确认（ACK）。
• 阶段二（Commit）：当 Leader 收到半数以上节点的 ACK 后，广播 Commit 消息，通知所有节点提交事务。此时数据正式生效。

数据持久化与同步

• 事务提交后，Leader 和 Follower 将数据持久化到内存数据库（DataTree）及磁盘日志文件（WAL）。
• 新加入的节点会通过 快照（Snapshot） 和 增量日志 完成数据同步。

客户端通知

• 写操作完成后，若客户端注册了 Watcher 监听器，Zookeeper 会通过 异步回调 通知客户端数据变化。

写成功条件：收到半数以上节点的 ACK（即满足 $n\ge \frac{N}{2}+1$）

zookeeper 动态上下线

Zookeeper 的动态上下线机制主要依赖其临时节点和 Watcher 监听机制实现。

实现流程

服务节点 Zookeeper集群 监控客户端 1. 创建临时节点 /servers/server1 2. 通知“子节点变化” (首次获取列表) 3. 注册Watcher监听 /servers 4. 心跳维持会话 5. 检测会话超时，删除临时节点 6. 触发Watcher回调通知 7. 重新获取最新服务列表 opt [服务下线/宕机] loop [动态维护] 服务节点 Zookeeper集群 监控客户端

1. 服务注册

   服务节点启动时，在 Zookeeper 的 /servers 路径下创建临时顺序节点（如 /servers/server000000001），节点数据存储服务元信息（IP、端口等）。

2. 服务发现

   客户端首次启动时，直接读取/servers 下所有子节点，获取当前可用服务列表。

3. 监听注册

   客户端通过 exists(path, true) 或 getChildren(path, true) 注册对 /servers 节点的子节点变更监听。

4. 动态更新

   • 服务上线：新服务注册节点 → Zookeeper 触发 NodeChildrenChanged 事件 → 客户端更新列表。
   • 服务下线：服务失联 → 会话超时 → 节点自动删除 → 触发事件 → 客户端更新列表。

zookeeper 分布式锁

Zookeeper 通过临时顺序节点 + Watcher 监听实现分布式锁，核心原理基于其强一致性和顺序性特征。

实现原理

是

否

客户端获取锁

创建临时顺序节点

是否为最小节点?

获取锁成功

监听前序节点

前序节点删除

1. 节点结构
   • 在 /locks 路径下创建临时顺序节点（如 /locks/lock_00000001）
   • 节点按创建顺序自动编号（00000001，00000002…）
2. 锁获取逻辑
   • 客户端检查自身节点是否为最小序号节点：
     • 是：获取锁。
     • 否：监听前序节点的删除事件（避免羊群效应）
3. 锁释放逻辑
   • 主动释放：删除自身节点
   • 被动释放：会话超时 → Zookeeper 自动删除临时节点
4. 异常处理
   • 会话断开：临时节点自动删除 → 锁释放
   • Watcher 丢失：重连后重新注册监听

代码示例

// 使用Curator简化实现
public class ZkDistributedLock {
    private final CuratorFramework client;
    private final String lockPath = "/locks/resource_lock";
    private InterProcessMutex lock;

    public ZkDistributedLock() {
        client = CuratorFrameworkFactory.newClient("localhost:2181", 
                new RetryNTimes(3, 1000));
        client.start();
        lock = new InterProcessMutex(client, lockPath); // 封装锁逻辑
    }

    public void executeWithLock(Runnable task) throws Exception {
        lock.acquire();  // 获取锁（阻塞）
        try {
            task.run();  // 执行业务代码
        } finally {
            lock.release();  // 释放锁
        }
    }
}

原生API实现关键步骤

// 1. 创建临时顺序节点
String nodePath = zk.create("/locks/lock_", 
                new byte[0], 
                ZooDefs.Ids.OPEN_ACL_UNSAFE, 
                CreateMode.EPHEMERAL_SEQUENTIAL);

// 2. 获取所有子节点并排序
List<String> children = zk.getChildren("/locks", false);
Collections.sort(children);

// 3. 判断是否为最小节点
int index = children.indexOf(nodePath.substring(nodePath.lastIndexOf('/') + 1));
if (index == 0) {
    return true; // 获取锁
}

// 4. 监听前序节点
String prevNode = children.get(index - 1);
zk.exists("/locks/" + prevNode, watchedEvent -> {
    if (watchedEvent.getType() == Watcher.Event.EventType.NodeDeleted) {
        // 前序节点删除 → 重新尝试获取锁
    }
});

技术优势

1. 避免死锁：临时节点自动清理
2. 公平锁：顺序节点保障先到先服务
3. 高可用：Zookeeper 集群保障服务