Mastering Distributed Locks: From Basics to Redlock and Beyond

Why Distributed Locks Matter

Distributed locks improve efficiency by preventing duplicate work across clients and ensure correctness by avoiding data inconsistency, lost updates, or duplicate orders when multiple processes access shared resources.

Three Core Properties

Mutual Exclusion : only one client may hold the lock at any time.

Dead‑lock Freedom : use a TTL (time‑to‑live) to guarantee automatic release if a client crashes or hangs.

Fault Tolerance : either run the lock service as a cluster (e.g., ZooKeeper, etcd) or use the Redlock approach of contacting multiple independent Redis nodes.

Common Implementations

Redis‑Based Lock

A naive approach uses SETNX followed by EXPIRE, which is not atomic. The correct pattern combines the two steps: SET lockKey requestId NX PX 30000 In Java with Jedis:

String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);

The requestId is a random, globally unique string used to verify ownership when releasing the lock.

Atomic Release with Lua

To avoid the non‑atomic GET ‑ DEL sequence, use a Lua script that checks the value and deletes the key in one step:

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

MySQL (ShedLock)

Create a table shedlock and use INSERT or UPDATE with a unique name and a lock_until timestamp. The lock is released by updating lock_until to the current time.

CREATE TABLE shedlock (
  name VARCHAR(64) PRIMARY KEY,
  lock_until TIMESTAMP(3) NULL,
  locked_at TIMESTAMP(3) NULL,
  locked_by VARCHAR(255)
);

ZooKeeper

Use an EPHEMERAL_SEQUENTIAL znode. The first client creates the node and holds the lock; others watch the smallest node and wait for its deletion. ZooKeeper’s session heartbeat automatically removes the lock if the client disconnects.

Redlock Algorithm

Contact N independent Redis masters, acquire the lock on a majority (⌊N/2⌋+1), measure the elapsed time, and adjust the remaining TTL. If the majority is not reached or the operation exceeds the original TTL, release any partial locks using the Lua script.

if (jedis.setnx(lockKey, val) == 1) {
    jedis.expire(lockKey, timeout);
}

Redlock relies on synchronized clocks; clock drift or jumps can break its safety guarantees.

Chubby

Google’s lock service adds a sequencer (a monotonic 64‑bit number) that clients can attach to requests. The resource server validates the sequencer via CheckSequencer() or by comparing with the latest sequencer, providing stronger safety than plain TTL‑based locks.

Common Pitfalls and Solutions

Non‑atomic lock acquisition/release can leave stale locks – use combined commands or Lua scripts.

Locks without expiration can cause deadlocks – always set a TTL.

Releasing another client’s lock – verify requestId before deletion.

Clock‑dependent algorithms (Redlock) are vulnerable to time jumps – consider ZooKeeper or Chubby which do not rely on system clocks.

Long‑running operations may exceed TTL – implement automatic renewal (watchdog) or use session‑based locks (ZooKeeper, Chubby).

Choosing the Right Lock

For high‑throughput, low‑latency scenarios Redis is suitable; for moderate concurrency with strong correctness guarantees ZooKeeper or Chubby are preferable; MySQL‑based locks are simple but suffer from single‑point bottlenecks.