Zookeeper Overview: Installation, Features, and Theory for High‑Concurrency Distributed Systems

Preface

High‑concurrency distributed development is a vast topic; this article is a personal learning summary rather than an authoritative guide. It aims to present the material simply, allowing readers to correct mistakes and add improvements together.

In large‑scale internet companies, RPC, Dubbo, and Zookeeper are fundamental skills. This article helps beginners understand Zookeeper's purpose, working principles, classic use cases, and interview‑level knowledge.

Getting to the Point

1. Challenges in Concurrent Environments

When multiple processes run across a cluster, we face issues such as keeping configuration consistent across machines, detecting node failures, adding new nodes without restarting the cluster, and coordinating concurrent writes to a shared network file.

2. Introduction to Zookeeper

① Origin of the Name

Many Apache projects use animal icons (Tomcat, Hive, etc.). Zookeeper’s role is to coordinate the actions of these “animals.”

② What Is Zookeeper?

Zookeeper is a high‑performance coordination service for distributed applications. Data is stored in memory with persistence via logs. Its tree‑like in‑memory structure provides high throughput and low latency, enabling distributed configuration centers, service registration, and distributed locks. Servers maintain a state graph and transaction logs; the service remains available as long as a majority of servers are up. Clients maintain a TCP connection to a single Zookeeper server and receive responses, watch events, and heartbeats.

③ Installation (Linux)

1. JDK version must be 1.6 or higher
2. Download: https://archive.apache.org/dist/zookeeper/zookeeper-3.5.2/zookeeper-3.5.2.tar.gz
3. In the extracted
conf
directory, add
zoo.cfg
4. Start the server:
bin/zkServer.sh start
5. Test client connection:
bin/zkCli.sh -server 127.0.0.1:2181
Key
zoo.cfg
settings:
   tickTime=2000   # basic heartbeat interval
   dataDir        # data and log storage directory
   clientPort=2181# client connection port

④ Key Characteristics

1. Simple Data Structure

Zookeeper stores data in a hierarchical namespace similar to a Unix file system. Each node (znode) can hold data and children. Paths are absolute, start with "/", and have size limits.

2. Data Model

Namespace is hierarchical; znodes have four types: persistent, sequential, ephemeral, and ephemeral‑sequential.

3. Naming Rules

Node names may use any Unicode character except a few prohibited ranges (null, control characters, etc.). The characters "." and ".." cannot be used alone because Zookeeper does not support relative paths.

4. Common Commands

Directory layout (Windows example):

bin   -> executable scripts for Linux/Windows
conf  -> configuration file
zoo.cfg
contrib -> additional components
dist-maven -> Maven‑published JARs
docs  -> documentation
lib   -> libraries
recipe-> example applications
src   -> source code (Java)

Start the server with bin\zkServer.cmd and the client with bin\zkClient.cmd . Use help , -help , or -h for command assistance.

5. Ordered Updates

Zookeeper assigns a monotonically increasing transaction ID (zxid) to every write, ensuring strict ordering of operations.

Zxid – global ordered transaction identifier.

Version numbers – dataVersion, cversion, aclVersion.

Ticks – heartbeat interval; session timeout is typically 2×tickTime.

Real time – Zookeeper does not rely on wall‑clock time.

6. Replication

Data is replicated across the ensemble, providing fault tolerance and eliminating single points of failure.

3. Zookeeper Theory

① Session Mechanism

1. Each client connection creates a session with a unique ID.
2. Clients send periodic heartbeats to keep the session alive.
3. If no heartbeat is received within the session timeout (default 2×tickTime), the session is considered dead.
4. Requests within a session are processed FIFO.

② Znode Data Composition

Node data: the actual payload (state, config, location, etc.)
Node metadata: information returned by the
stat
command
Data size limit: 1 MiB

③ Znode Types

1. Persistent node – created with
create path value
2. Ephemeral node – created with
create -e path value
3. Sequential node – created with
create -s path value
Notes:
   • Ephemeral nodes disappear when the session ends.
   • Sequential nodes receive a 10‑digit decimal suffix; the counter overflows at 2 147 483 647.
   • Sequential nodes persist after the session ends.

④ Watch Mechanism

Clients can set watches on znodes to be notified of create, delete, change, or child events. Watches are one‑time triggers; after firing they are removed.

1. One‑time: watch is removed after it fires.
2. Ordered: client receives the notification before reading the change.

⑤ Core Guarantees

1. Sequential consistency – operations appear in order.
2. Atomicity – updates succeed completely or not at all.
3. Single system image – all clients see the same state.
4. Reliability – changes are not lost unless overwritten.
5. Timeliness – reads return the latest data.

Conclusion

After this overview, readers should have a basic understanding of Zookeeper and be prepared to explore distributed locks, cluster management, and real‑world use cases in future articles.