Mastering ZooKeeper: Core Concepts, Architecture, and Practical Setup

ZooKeeper Overview

ZooKeeper is an open‑source distributed coordination service and storage system widely used in the big‑data ecosystem (Hadoop, Storm, HBase, Spark, Flink, Kafka). It excels in coarse‑grained distributed locks, leader election, and high‑availability failover where high TPS is not required.

Typical Application Scenarios

Common uses include centralized configuration management for micro‑service systems, group membership management (e.g., HBase clusters), various distributed locks (not suitable for large data volumes), and service registry for many small‑to‑medium companies. ZooKeeper is unsuitable for massive data storage because it keeps the entire data tree in memory and prioritizes coordination over storage performance.

Source Code Environment

When exploring ZooKeeper source, two key steps are version selection and environment preparation. Major versions are 3.4.x (most common in enterprise), 3.5.x, and 3.6.x. The recommended version is zookeeper-3.4.14.tar.gz , which bundles source and binaries together. Set up an IDE (e.g., IntelliJ IDEA), download the source package from the official site or clone from GitHub, and let Maven resolve required dependencies.

Serialization Mechanism

Serialization is needed for network transmission and disk persistence. Java serialization uses ObjectInputStream and ObjectOutputStream . Hadoop provides its own serialization framework. ZooKeeper relies on the Jute library (module zookeeper-jute ) with key APIs: org.apache.jute.InputArchive : interface for deserialization methods (read*). org.apache.jute.OutputArchive : interface for serialization methods (write*). org.apache.jute.Index : iterator for deserialization. org.apache.jute.Record : objects exchanged over the network must implement this interface, providing both serialize and deserialize methods.

Persistence Mechanism

The data model consists of ZKDataBase , DataTree , and DataNode . Persistence is handled by TxnLog (transaction log) and SnapLog (snapshot). Each node stores the full data tree in memory and a copy on disk to balance read/write performance. Core classes: TxnLog interface and FileTxnLog implementation for transaction logs. Snapshot interface and FileSnap implementation for snapshots. FileTxnSnapLog encapsulates both log and snapshot. Util provides utility APIs for persistence.

Network Communication Mechanism

Java I/O options include BIO (blocking), NIO (non‑blocking, reactor‑based), and AIO (asynchronous). ZooKeeper primarily uses NIO, with Netty as an alternative. Important NIO APIs are Buffer, Channel, and Selector. Connection classes: ServerCnxn (server‑side connection component). ClientCnxn (client‑side communication component). Implementations: NIOServerCnxn (NIO‑based) and NettyServerCnxn (Netty‑based).

Watcher Working Mechanism

Client‑side watcher registration involves several classes: org.apache.zookeeper.ZooKeeper : main client class holding ClientCnxn and ZkWatchManager . ZKWatchManager : stores dataWatches, existWatches, childWatches, and defaultWatcher. org.apache.zookeeper.ClientCnxn : manages outgoing packet queue, SendThread , and EventThread . WatchRegistration : wraps a Watcher and its client path. Packet : internal class representing a request/response packet. Workflow when getData is called with a custom Watcher: Client creates a request and submits it via ClientCnxn.submitRequest , embedding a WatchRegistration in a Packet and adding it to outgoingQueue . SendThread pulls the packet, sends it to the server, and moves it to pendingQueue while awaiting a response. Upon response, ClientCnxn.finishPacket extracts the WatchRegistration and registers the Watcher in the appropriate collection (dataWatches, existWatches, or childWatches) via ZKWatchManager .

Conclusion

The article continues in the next part, further analyzing ZooKeeper internals.