ZooKeeper 数据模型与存储结构深度解析

Seal^_^

3134人浏览 · 2026-03-13 13:44:45

Seal^_^ · 2026-03-13 13:44:45 发布

ZooKeeper 数据模型与存储结构深度解析

🌺The Begin🌺点点关注，收藏不迷路🌺

摘要：ZooKeeper作为分布式协调服务，其数据模型和存储结构是理解其工作机制的基础。本文将深入剖析ZooKeeper的逻辑数据模型（树形结构的ZNode）和物理存储结构（内存数据库 + 事务日志 + 数据快照），通过源码分析和流程图，帮助读者全面掌握ZooKeeper的数据管理机制。

一、ZooKeeper数据模型概述

ZooKeeper的数据模型是一个层次化的命名空间，结构上非常类似于标准的文件系统。

1.1 核心概念：ZNode

树中的每个节点称为ZNode（ZooKeeper Node）。每个ZNode都可以存储数据，也可以拥有子节点。

特性	说明
路径标识	每个ZNode通过绝对路径唯一标识，如 `/app1/serviceA`
数据存储	默认最大存储1MB数据，适合存储配置、状态等元数据
原子操作	读操作获取完整数据，写操作替换全部数据，不支持部分读写
兼具文件/目录特性	既可以存储数据（像文件），也可以有子节点（像目录）

1.2 ZNode的三种组成部分

每个ZNode由三部分构成：

data：存储的业务数据（字节数组）
stat：状态信息，包括版本号、时间戳、事务ID等
children：子节点列表

二、ZNode的四种类型

ZNode在创建时确定类型，之后不可更改。

类型	创建参数	生命周期	是否有子节点	典型应用
持久节点	`PERSISTENT`	直到显式删除	可以	配置信息、元数据
临时节点	`EPHEMERAL`	会话结束自动删除	不能有子节点	服务注册、心跳检测
持久顺序节点	`PERSISTENT_SEQUENTIAL`	持久存在，带递增序号	可以	任务队列、事件顺序
临时顺序节点	`EPHEMERAL_SEQUENTIAL`	会话结束自动删除，带序号	不能有子节点	分布式锁、Leader选举

顺序节点的命名规则：在指定路径后自动追加10位数的递增序号，如 /task/task-0000000001。

三、ZNode的Stat属性详解

每个ZNode维护着一套丰富的状态信息（stat），记录了节点的所有元数据。

字段	说明	作用
cZxid	创建节点的事务ID	记录创建时刻
mZxid	最后修改节点的事务ID	记录最后修改时刻
pZxid	最后修改子节点的事务ID	子节点列表变化时更新
ctime	创建时间（毫秒）	节点创建时间戳
mtime	最后修改时间（毫秒）	节点数据最后修改时间
dataVersion	数据版本号	每次数据修改+1，用于乐观锁
cversion	子节点版本号	子节点新增/删除时+1
aclVersion	ACL版本号	权限修改时+1
ephemeralOwner	临时节点所有者会话ID	0表示持久节点，非0表示临时节点
dataLength	数据长度（字节）	监控数据大小
numChildren	子节点数量	监控节点负载

版本号的作用：ZooKeeper通过版本号实现乐观锁机制，防止并发修改导致的数据不一致。

四、存储结构：内存+磁盘

ZooKeeper的数据存储分为两部分：内存数据和磁盘数据（事务日志 + 数据快照）。

4.1 内存数据：ZKDatabase

ZooKeeper将所有数据全量存储在内存中，这是其高性能读写的关键。

核心数据结构：

// 源码示意：DataTree类定义内存数据结构
public class DataTree {
    // 节点存储：路径 -> DataNode
    private final ConcurrentHashMap<String, DataNode> nodes = 
        new ConcurrentHashMap<>();
    
    // 临时节点索引：会话ID -> 该会话创建的所有临时节点
    private final ConcurrentHashMap<Long, HashSet<String>> ephemerals = 
        new ConcurrentHashMap<>();
    
    // Watcher管理器
    private final WatchManager dataWatches = new WatchManager();
    private final WatchManager childWatches = new WatchManager();
    
    private static final String rootZookeeper = "/";
}

DataNode结构：

public class DataNode {
    // 父节点引用
    DataNode parent;
    // 节点数据
    byte[] data;
    // ACL权限
    Long acl;
    // 节点状态
    StatPersisted stat;
    // 子节点列表
    Set<String> children = new HashSet<>();
}

4.2 事务日志

事务日志记录了ZooKeeper处理的每一次写操作，用于数据恢复和集群同步。

配置位置：

dataDir：事务日志存储目录
dataLogDir：可单独配置日志目录（生产环境推荐分离）

文件命名：log. + 十六进制的ZXID，如 log.100000001

日志格式：

ZooKeeper Transactional Log File with dbid 0 txnlog format version 2
11:07:41 session 0x144699552020000 cxid 0x0 zxid 0x300000002 createSession 3000
11:08:40 session 0x144699552020000 cxid 0x2 zxid 0x300000003 create `/test_log,#7631,v{...}

写入机制：

预分配：每个日志文件预先分配64MB空间，避免频繁磁盘分配
追加写入：新事务以追加方式写入当前日志文件
强制刷盘：可配置是否每次写入后强制刷盘（forceSync）

4.3 数据快照

数据快照是内存数据的全量备份，用于加快恢复速度。

文件命名：snapshot. + 十六进制的ZXID，如 snapshot.100000001

触发时机：通过snapCount参数控制，默认每100000次事务记录后触发一次快照

// 快照触发条件：满足"过半随机"条件
randRoll = random(1, snapCount / 2);
logCount > (snapCount / 2 + randRoll);
// 实际触发范围在 50000 到 100000 次事务之间

快照过程：

切换新的事务日志文件
创建异步线程进行快照
序列化DataTree和会话信息
写入磁盘文件

五、数据恢复流程

当ZooKeeper服务器启动时，会从磁盘加载数据恢复到内存中。

恢复要点：

快照文件可能滞后于内存数据，需通过事务日志补充增量部分
如果连续100个快照文件都不可用，服务启动失败
恢复过程中会重建提议缓存队列committedLog，用于Follower快速同步

六、数据同步机制

集群完成Leader选举后，Learner需要与Leader进行数据同步。

Leader根据Learner上报的lastZxid决定同步策略：

同步类型	触发条件	操作
DIFF同步	peerLastZxid在committedLog范围内	发送缺失的事务提案
TRUNC同步	peerLastZxid > maxCommittedLog	截断多余事务日志
TRUNC+DIFF	需要回滚后增量同步	先回滚，再增量同步
SNAP全量同步	peerLastZxid < minCommittedLog	发送完整快照