Mastering ZooKeeper: Core Concepts, Architecture, and Real‑World Use Cases

1. What is ZooKeeper?

ZooKeeper is an open‑source distributed coordination service that provides consistency for distributed applications, enabling features such as publish/subscribe, load balancing, naming, distributed notifications, cluster management, master election, distributed locks and queues.

2. What does ZooKeeper provide?

It offers a hierarchical namespace of znodes (similar to a file system) where each node can store data. The in‑memory tree structure ensures high throughput for reads but limits each node’s data size to 1 MB.

3. ZooKeeper file system

Unlike a traditional file system, every znode can hold data. Persistent, ephemeral, sequential and ephemeral‑sequential node types are supported.

4. How does ZooKeeper keep leader and follower states synchronized?

The core is the atomic broadcast (ZAB) protocol, which operates in recovery mode and broadcast mode to achieve state sync among servers.

5. Types of znodes

PERSISTENT – remains until explicitly deleted.

EPHEMERAL – tied to the client session and removed when the session ends.

PERSISTENT_SEQUENTIAL – persistent with an auto‑incremented suffix.

EPHEMERAL_SEQUENTIAL – ephemeral with an auto‑incremented suffix.

6. Watcher mechanism – data change notification

Clients register a watcher on a znode; when the node changes, the server sends a one‑time event to the client. Watchers are removed after they fire.

7. ACL permission control

ZooKeeper supports UGO (user/group/others) style permissions, ACL schemes (IP, digest, world, super) and permissions such as CREATE, DELETE, READ, WRITE, ADMIN.

8. Chroot feature

Since version 3.2.0 a client can set a chroot to restrict all its operations to a specific subtree.

9. Session management

Sessions are managed in buckets; expiration time = current time + session timeout, rounded to the next tick interval.

10. Server roles

Leader (handles all proposals), Follower (processes client requests and votes), Observer (does not vote, improves read capacity).

11. Server states

LOOKING, FOLLOWING, LEADING, OBSERVING.

12. Data synchronization

Four sync modes: DIFF, TRUNC+DIFF, TRUNC, SNAP, chosen based on the learner’s last zxid relative to the leader’s committed log.

13. Transaction order consistency

Each proposal receives a globally increasing zxid (epoch + counter). A proposal is committed only after a majority of servers acknowledge it.

14. Why a master node is needed

Leader election ensures that only one node performs certain exclusive tasks, reducing duplicate work.

15. Node failure handling

A ZooKeeper ensemble of at least three servers can tolerate one failure; the majority must stay alive for the service to continue.

16. Load balancing vs. Nginx

ZooKeeper’s built‑in load balancing is configurable but less performant than Nginx, which excels in raw throughput.

17. Deployment modes

Standalone, cluster, and pseudo‑cluster (multiple instances on one machine).

18. Dynamic scaling

Older versions require a full restart; from 3.5 onward ZooKeeper supports dynamic expansion.

19. Watcher lifetime

Watchers are one‑time triggers; they are removed after firing to avoid excessive network load.

20. Java clients

ZooKeeper provides its own client and the Apache Curator library.

21. Comparison with Chubby

Chubby is Google’s proprietary Paxos‑based service; ZooKeeper is an open‑source implementation using the ZAB protocol, a Paxos variant.

22. Common commands

ls, get, set, create, delete, etc.

23. Typical use cases

Configuration management, service discovery, naming, distributed notifications, cluster management, master election, distributed locks and queues.

Author: ThinkWon – Source: https://blog.csdn.net/ThinkWon/article/details/104397719