Examples of Powerful Primitives by Zookeeper API

Configuration management

Zookeeper’s API can configure management simply by publishing the node with some configuration information. Create a znode $z_c$ and write the configuration as the znode’s data.

The znode’s path is provided to the other nodes of the system, which obtain the configuration by reading $z_c$. They also register a watch so that they are informed when this configuration changes. If that happens, they are notified and perform a new read to get the latest configuration.

Group membership

A node $z_g$ is designated to represent the group. When a node wants to join the group, it creates an ephemeral child node under $z_g$. If each node has a unique name or identifier, this can be used as the name of the child node.

Alternatively, the nodes can use the sequential flag to obtain a unique name assignment from Zookeeper. These nodes can also contain additional metadata for the group members, such as addresses and ports.

Nodes can obtain the members of the group by listing the children of $z_g$. If a node also wants to monitor changes in the group membership, it can register a watch. When nodes fail, their associated ephemeral nodes are automatically removed, which signals their removal from the group.

Simple locks

We can implement lock by simply using a lock file represented by a znode.

To acquire a lock, a client tries to create the designated znode with the ephemeral flag. If the create succeeds, the client holds the lock. Otherwise, the client can set a watch to notify the created node .So when the lock is released, it can attempt to re-acquire it. The lock is released when the client explicitly deletes the znode or when it dies.

Locks without herd effect

The process of acquiring a lock file suffers from the herd effect. If many clients are waiting to acquire a lock, they will all be notified simultaneously. They will attempt to acquire the lock even though only one can acquire it, thus creating unnecessary contention.

There is a different way to implement locks to avoid this problem. All the clients compete for the lock file to create a sequential, ephemeral znode with the same prefix (i.e. /lock-). The client with the smallest sequence number will acquire the lock. The rest of the clients will register watches for the znode with the next lower sequence number. Once a node gets notified, it checks if it’s now the lowest sequence number, which means it can acquire the lock. Otherwise, it registers a new watch for the next znode with the lower sequence number.

Note:Many more primitives such as read/write locks, barriers etc can be built in the similar pattern by using the Zookeeper’s API . These patterns in Zookeeper are usually called recipes.