Master Zookeeper: From Installation to Advanced Coordination in Distributed Systems

1. Challenges in Concurrent Environments

When multiple servers form a cluster to handle high traffic, questions arise: how to keep configuration consistent across machines, detect node failures, add new nodes without restarting, and coordinate writes to shared network files.

2. Introduction to Zookeeper

① Origin of the Name

Zookeeper, like other Apache projects named after animals, coordinates the actions of distributed components.

② Overview

Zookeeper is a high‑performance coordination service for distributed applications. Data resides in memory with persistence via logs. It provides a tree‑like namespace, high throughput, low latency, and supports distributed configuration, service registration, and locks. A quorum of servers must be available for the service to be up, and clients maintain a TCP connection to a single server, automatically switching on failure.

③ Installation (Linux)

1. JDK version >= 1.6
2. Download: https://archive.apache.org/dist/zookeeper/zookeeper-3.5.2/zookeeper-3.5.2.tar.gz
3. Add zoo.cfg in the conf directory after extraction
4. Start server: bin/zkServer.sh start
5. Test client: bin/zkCli.sh -server 127.0.0.1:2181

Key zoo.cfg settings:
  tickTime=2000   # heartbeat interval
  dataDir         # data and log directory
  clientPort      # client port

④ Key Characteristics

1. Simple Data Structure

Znodes form a hierarchical tree similar to a Unix file system; each node can store data and act as a folder. Paths are absolute, starting with "/", and node data size is limited.

2. Data Model

Hierarchical namespace with four node types: persistent, sequential, ephemeral, and ephemeral‑sequential.

3. Naming Rules

1. Null character (\u0000) not allowed in paths
2. Control characters (\u0001‑\u0019, \u007F‑\u009F) prohibited
3. Unicode ranges \ud800‑\uf8ff and \uFFF0‑\uFFFF disallowed
4. "." and ".." cannot be used as standalone path components
5. "zookeeper" is a reserved node name

4. Common Commands

Typical directory layout:

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

Start the server with

bin/zkServer.cmd

and the client with

bin/zkCli.cmd

. Use commands like

ls /

,

create /zk 123

, noting that

create

requires a parent node and

delete

cannot remove a node with children.

5. Ordered Updates

Zookeeper assigns a monotonically increasing transaction ID (zxid) to each write, ensuring strict ordering. It also tracks version numbers (dataVersion, cversion, aclVersion) and uses tickTime to define session timeouts.

6. Replication

Data is replicated across the ensemble, providing fault tolerance and eliminating single‑point failures.

7. Performance

Its design makes Zookeeper suitable for large‑scale distributed systems.

3. Zookeeper Theory

① Session Mechanism

1. Each client gets a unique session ID.
2. Clients send periodic heartbeats to keep the session alive.
3. If no heartbeat is received within 2×tickTime, the session expires.
4. Requests within a session are processed FIFO.

② Znode Data Composition

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

③ Node Types

1. Persistent node: created with <code>create path value</code>
2. Ephemeral node: created with <code>create -e path value</code>
3. Sequential node: created with <code>create -s path value</code>

Notes:
- Ephemeral nodes disappear when the session ends.
- Sequential nodes receive a 10‑digit decimal suffix; the counter overflows after 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, requiring re‑registration for continuous monitoring. Notifications are ordered, and there may be latency, so watches are not absolutely reliable.

⑤ Zookeeper 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, you should have a solid foundation of Zookeeper’s architecture, installation, and core features, preparing you to explore distributed locks, cluster management, and real‑world use cases.