ZooKeeper ZNode Data Structure and Watcher Mechanism Details

This is article 28 in the Big Data series. Detailed introduction to ZooKeeper ZNode node types, internal data structure, ZXID transaction ID, and Watcher monitoring mechanism core principles.

Complete illustrated version: CSDN Original | Juejin

ZNode: Data Unit of ZooKeeper

ZooKeeper organizes data in tree structure similar to Unix filesystem, each node called ZNode. Paths separated by /, root is /, e.g., /app/config/db-host.

ZNode Internal Structure

Each ZNode stores both data and metadata:

Field	Description
data	Byte array, max ~1 MB
dataVersion	Data version number, auto-increments after each setData
cversion	Child node version number, auto-increments after child add/delete
aclVersion	ACL permission version number
ctime	Node creation timestamp
mtime	Node last modification timestamp
ephemeralOwner	Session ID of ephemeral node owner; 0 for persistent nodes
numChildren	Number of child nodes

ZNode designed for storing metadata and configuration, not suitable for large business data.

ZNode Four Types

1. Persistent Node

Exists permanently after creation until explicitly deleted. Suitable for storing configuration, service metadata, and other information that needs long-term retention.

create /app/config "prod"

2. Persistent Sequential Node

Automatically appends 10-digit incrementing sequence number to path end, sequence number globally monotonic increasing.

create -s /jobs/task "payload"
# Actually created: /jobs/task0000000001
# Created again: /jobs/task0000000002

Applicable scenarios: Distributed queue, ordered task allocation.

3. Ephemeral Node

Bound to client Session lifecycle: Node automatically deleted after Session disconnects (timeout or主动关闭). Ephemeral nodes cannot have child nodes.

create -e /services/instance-a "192.168.1.10:8080"

Applicable scenarios: Service registration (auto deregister on offline), heartbeat detection.

4. Ephemeral Sequential Node

Both “auto delete” and “globally ordered” features, core primitive for implementing fair distributed locks and Leader election.

create -e -s /lock/node "client-1"
# Actually created: /lock/node0000000001

When competing for lock, node with smallest sequence number holds lock; after lock holder disconnects, next sequence number node receives notification and acquires lock.

ZXID: Transaction ID

ZooKeeper assigns globally unique 64-bit transaction ID (ZXID) for each write operation:

| High 32 bits (epoch) | Low 32 bits (counter) |

• epoch: Increments after each Leader election, identifies current Leader term
• counter: Transaction sequence within current Leader term, increments on each write operation
• Globally monotonic increasing: Between different epochs, high bits ensure overall order

ZXID roles:

1. ZAB Protocol Consistency: Followers decide whether to accept Leader’s transaction proposal by comparing ZXID
2. Crash Recovery: After node restarts, compares ZXID to sync missing transactions from Leader
3. Order Guarantee: Client requests executed in ZXID order, ensuring sequential consistency

Watcher Monitoring Mechanism

Watcher is an event-driven notification mechanism provided by ZooKeeper, allowing clients to subscribe to ZNode state changes and receive notifications asynchronously when changes occur.

Core description: “One-time trigger, asynchronous notification, lightweight transmission”.

Core Features

Feature	Description
One-time trigger	Watcher automatically expires after triggering once, needs re-registration
Asynchronous	Notification doesn’t block client normal operations
Lightweight	Notification only contains event type and node path, not full data
Ordered	Same client event notifications arrive in trigger order

Registration Methods

# Register data monitoring
get -w /app/config

# Register child node monitoring
ls -w /services

Event Types

Event	Trigger Condition
NodeCreated	Monitored node created
NodeDeleted	Monitored node deleted
NodeDataChanged	Node data modified (setData)
NodeChildrenChanged	Node’s child node list changed

Practice Demonstration

Register monitoring and wait in one terminal:

zkCli.sh -server h121.wzk.icu:2181

# Write data to root node, register Watcher at same time
get -w /

Modify data in another terminal:

zkCli.sh -server h122.wzk.icu:2181
set / wzk.icu

First terminal will immediately receive notification:

WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/

Cross-node sync verification: After writing data to any node, other nodes can immediately read latest value, verifying ZAB protocol’s strong consistency.

Watcher Usage Precautions

1. Must re-register: After receiving each notification, if still need monitoring, must immediately call getData/getChildren/exists to re-register
2. Notifications may be lost: Changes before re-registration won’t trigger notifications, high-frequency change scenarios need to combine with polling
3. Lightweight design: Notification doesn’t carry changed data, client must actively query latest data after receiving notification

Summary

ZNode four types (persistent/persistent sequential/ephemeral/ephemeral sequential) form the foundation primitives for all ZooKeeper advanced features. ZXID ensures global write operation order, Watcher one-time trigger mechanism achieves distributed event notification with low overhead. Next article will demonstrate Watcher registration and trigger process via command line practice.