ZooKeeper Core Concepts: Data Model, Node Types, Sessions, Cluster, Election, ZAB, Watch, ACL, and Distributed Lock Patterns

ZooKeeper stores its data in a tree‑like structure with a fixed root node; child nodes are created under the root and further sub‑nodes can be added, using absolute paths such as get /work/task1 for queries.

ZooKeeper cannot use relative paths because it internally stores nodes in a hashtableConcurrentHashMap<String, DataNode> nodes where the full path is the key.

Node types include:

Persistent nodes : remain on the server even after the client session ends; they must be explicitly deleted with the delete command.

Ephemeral nodes : exist only while the creating client session is alive; they are automatically removed when the session expires, and are often used to track live servers under a /servers path.

Sequential nodes : ZooKeeper appends a monotonically increasing number to the node name (e.g., creating works/task- results in works/task-1 ).

Each node stores a binary byte data[] array, ACL information, child‑node data (null for ephemerals), and a stat field describing its state.

Node state can be inspected with commands such as stat /zk_test , and each node maintains three version counters that change on any update.

Data is kept in memory (managed by the DataTree class) and persisted via transaction logs, snapshots, and a separate data log that records server runtime status.

Sessions are created when a client connects to a server; a session consists of a session ID, timeout, and a closing flag. The timeout negotiated between client and server determines the actual server‑side timeout.

Session states include CONNECTING, CONNECTED, RECONNECTING, RECONNECTED, and CLOSED.

ZooKeeper clusters consist of three server roles: Leader (coordinates the cluster), Follower (processes non‑transactional client requests), and Observer (handles read‑only requests and does not participate in leader election).

Leader election occurs when the current leader fails; followers vote using fields such as myid and ZXID . Votes are compared first by logical clock, then by vote_zxid , and finally by vote_myid to select the new leader.

The ZAB (Zookeeper Atomic Broadcast) protocol ensures consistency across the cluster, handling both crash recovery and atomic broadcast of transaction logs.

Watch mechanisms allow clients to subscribe to changes on nodes; watches are one‑time triggers and must be re‑registered after firing.

Access control lists (ACLs) are defined as scheme:id:permission strings, with schemes such as world, IP range, and digest, and permissions including create, write, read, delete, and admin.

Common application scenarios include implementing distributed locks:

Using a single lock node (e.g., /locks ) where only one client can create the node.

Using sequential child nodes under a lock path; the client with the smallest sequence number acquires the lock, releasing it by deleting its node.

These lock designs address issues such as deadlock risk and the “herd effect” by ensuring only one waiting client is notified when a lock is released.