Implementing Distributed Locks with Redis: The RedLock Algorithm

Use Redis to Build Distributed Locks

When multiple processes need mutually exclusive access to shared resources, a distributed lock is essential. This article introduces the official RedLock algorithm, which improves reliability over simple single‑instance locks.

Implementation

Various language implementations exist (Ruby, Python, PHP, Go, Java, etc.). The core idea is to use the Redis command SET resource_name my_random_value NX PX 30000 to acquire a lock only if the key does not exist, with a timeout.

A Lua script ensures that a lock is released only by its owner:

if redis.call("get",KEYS[1]) == ARGV[1] then
  return redis.call("del",KEYS[1])
else
  return 0
end

Safety and Reliability Guarantees

Three properties are required: mutual exclusion, dead‑lock‑freedom, and fault‑tolerance (a majority of nodes must be up).

Why Simple Failover Is Insufficient

Using a master‑slave setup introduces a race condition when the master fails before replication, breaking the mutual‑exclusion guarantee.

RedLock Algorithm

The algorithm runs on N independent Redis masters (commonly N=5). A client:

Gets the current time in milliseconds.

Attempts to acquire the lock on each master with a short TTL.

Succeeds if it obtains locks on a majority (N/2+1) and the total elapsed time is less than the TTL.

Adjusts the remaining TTL accordingly.

If it fails, it releases any acquired locks.

Retrying uses random back‑off to avoid thundering‑herd effects.

Performance and Fault Recovery

High throughput is achieved by parallel requests to all masters. Persistence (AOF, fsync) and careful restart strategies are discussed to maintain safety during node failures.

Extending Locks

Clients can extend the lock lifetime with another Lua script if work takes longer than the original TTL.

The article invites readers to analyze the algorithm’s safety proof and contribute implementations.