CodeParkRedlock is an algorithm from the Redis docs for locks across N independent primaries, usually 5. The client tries to take the same key, with a random token, on each primary. It holds the lock only if it got a majority of them, in a time well under the TTL.
Martin Kleppmann's criticism: Redlock depends on timing assumptions.
- A GC (garbage collection) pause, a frozen process or a network delay can make a client believe it still holds the lock after it expired.
- Clock jumps on the Redis nodes can expire locks too early.
- Redlock gives no fencing token. A fencing token is a number that always goes up with each new lock. Without it, the protected storage cannot reject writes from an old holder.
In practice:
- For efficiency locks, where a rare double run is acceptable, a single Redis lock is fine.
- For correctness, use fencing tokens that the resource checks, a consensus-based system such as ZooKeeper or etcd, or a database constraint.
- The client must take the lock on a majority of independent primaries within the TTL.
- Kleppmann showed that pauses, delays and clock jumps break its safety.
- It has no fencing tokens, so the resource cannot reject old holders.
- It is fine for efficiency, but risky for correctness.
- For correctness, use fencing tokens or consensus-based locks.