Implementing Distributed Locks with Redis and Zookeeper

1. Redis‑Based Distributed Lock Implementation

Redis is a key‑value NoSQL store often used for caching. Starting from Redis v2.6.12, the SET command supports atomic options:

SET key value [EX seconds] [PX milliseconds] [NX|XX]

EX sets an expiration time, while NX ensures the key is set only if it does not already exist – the core mechanism for a Redis lock.

Typical lock acquisition scenarios:

Node A obtains the key with an expiration; if it crashes before releasing, the expiration automatically frees the lock.

If a node crashes before setting the expiration, the atomic SET … NX EX fails and returns 0, preventing a lock from being acquired.

2. Releasing the Lock

To avoid non‑atomic release, a Lua script is commonly used because the script runs atomically, similar to a transaction. The article includes an illustration of such a script (see image).

2. Zookeeper‑Based Distributed Lock Implementation

Zookeeper provides distributed coordination via znodes. There are four znode types:

Persistent node : remains after the client disconnects.

Persistent sequential node : created with an automatically incremented suffix based on creation order.

Ephemeral node : deleted when the client session ends.

Ephemeral sequential node : combines sequential naming with automatic deletion on session loss.

Lock acquisition using these nodes follows these steps:

Create a persistent parent node (if not existing). When a client wants a lock, it creates an ephemeral sequential child under this parent.

All clients list the sequential children, sort them, and the client whose node has the smallest sequence number obtains the lock.

If a client’s node is not the smallest, it registers a watcher on the next‑smaller node to be notified when that node disappears, indicating the lock may become available.

The article illustrates the process with three clients (Client1, Client2, Client3) showing how each creates a sequential node, checks ordering, and either acquires the lock or watches the predecessor.

2. Releasing the Lock

Because the lock is represented by an ephemeral sequential node, it is automatically removed when the client finishes its task or crashes, freeing the lock for others.