The Redlock algorithm.

A single Redis lock with SET resource <token> NX PX 30000 holds until the one Redis server fails. With master–replica replication, a race opens at failover. Client A acquires the lock on the master. The master crashes before the write replicates to the replica. The replica is promoted to master. Client B then acquires the same lock — the new master carries no record of A’s lock.

Two clients are now both granted the same lock. The mutual-exclusion guarantee is violated: two holders at once, which is exactly what a lock must prevent. The acquire is safe on one node; the gap opens only across a master–replica handoff. This is the weakness Redlock is built to remove.

Redlock uses N independent Redis masters — typically 5 — with no replication between them. A lock counts as acquired only when a client holds it on a majority of instances: N/2+1, so at least 3 of 5. The acquire is time-checked end to end.

Release runs the same token-checked Lua script on every instance — GET == token then DEL — so a delete only lands on a lock this client still owns. Always attempt the release on all instances, even those where the acquire appeared to fail; a network blip can produce a false negative. The random retry delay desynchronizes competing clients and reduces contention.

Redlock targets three properties.

• Safety — mutual exclusion. At most one client holds the lock at a time, as long as the client finishes its work within the validity time. If the lease expires mid-work, a second client may acquire it.
• Liveness — deadlock freedom. A lock eventually frees even when the holder crashes, because the TTL releases it automatically — the same mortality the single-instance PX gives, now across N nodes.
• Liveness — fault tolerance. While a majority of instances are reachable, clients can acquire and release locks. This is the property a single-instance lock cannot offer, and the whole reason to run more than one.

Redlock assumes clocks on different machines advance at approximately the same rate. It does not require synchronized clocks — only that a local clock does not drift significantly relative to the TTL. The algorithm is immune to network delay during the acquire because it re-checks the time at T2: if too much time elapsed, the lock is treated as invalid even when a majority responded OK. The vulnerability is a clock jump — a manual time change or an aggressive NTP correction — which can move a clock past the lease and break the safety argument. The drift allowance, typically 1–2% of the TTL, is the safety margin subtracted from the usable validity:

Automatic expiry creates a hazard shared by every distributed lock: client A acquires the lock; A pauses (GC, a context switch, a scheduler stall); the lock expires; client B acquires it; A resumes and proceeds as a holder; two clients now operate on the shared resource at once.

The stronger fix is a fencing token: on acquire, also obtain a monotonically increasing token; every operation on the resource carries the token; the resource rejects any operation whose token is older than the highest it has seen. A paused, stale writer is fenced out at the resource, not merely warned at the lock. Redlock’s random value can serve as a check-and-set token, but it carries no ordering, so it does not fence on its own.

Redlock fits work where approximate mutual exclusion is enough and fault tolerance matters: coordinating access to an external resource with no built-in concurrency control, preventing duplicate job execution in a distributed queue, approximate distributed rate limiting, and leader election among application instances.

Reach for an alternative when the requirements harden — absolute correctness, a linearizable resource, a case where one Redis node is enough, or a setting where five independent instances cost more than the guarantee is worth.

The algorithm’s safety rests on a handful of concrete settings.

Martin Kleppmann published a critique arguing Redlock is unsafe for correctness-critical work, primarily because of its timing assumptions, and that a fencing token from the protected resource is the real fix. Salvatore Sanfilippo (antirez, the Redis creator) replied defending the algorithm’s practical safety, arguing the timing checks are sufficient under real conditions.

The disagreement centres on whether those timing checks are enough to prevent a safety violation in practice. Both agree on one thing: a fencing token is the stronger guarantee where the resource supports one. Where a lock violation would corrupt data, reach for a consensus system or ensure the resource layer fences.

The whole trade collapses to a four-row table: Redlock buys fault tolerance and consistency-through-failover with the complexity of five instances, while a single instance stays simple and loses the lock when its one node fails.

EchoMQ does not implement Redlock. Its “lock” is the claim lease, and it lives on one Valkey, reached through one EchoMQ.Connector. The @claim script (echo/apps/echo_mq/lib/echo_mq/jobs.ex:126) is one atomic Lua transition: it pops the next id from pending with ZPOPMIN, increments the fencing token with HINCRBY <job> attempts 1, marks the row active, reads one server clock with redis.call('TIME'), and stamps the lease with ZADD active now + lease_ms <id>. No cross-node clock is compared, because there is only one clock; no votes are counted, because there is only one master.

The pause that breaks Redlock is handled without a fencing token at the resource and without five masters. The attempts counter, returned to the worker by @claim, is the fence: @complete and @retry refuse a stale token with EMQSTALE … token mismatch, so a worker whose lease was reaped and re-claimed by another worker carries the old attempts and is rejected at the write. The reclaim itself is Jobs.reap (consumer.ex:93), which on the same server clock returns every expired lease in active to pending — crash recovery, not a vote. A lost lease is a re-claim by the next worker; because the work is idempotent, that re-run is safe.

Each dive takes one part of the contrast, following the source in order: the majority mechanic that gives the fault tolerance, the timing argument the whole debate turns on, and the contrast resolved — when a single-Valkey lease is enough.