Redis Redlock is a distributed locking algorithm designed by Salvatore Sanfilippo (a.k.a. antirez, the creator of Redis) to provide mutual exclusion in a distributed Redis setup — i.e., when you have multiple Redis nodes (not just a single instance).
It's intended for scenarios where you want to ensure that only one node or process can hold a lock at a time across a cluster, even if nodes crash or network partitions happen.
Use Case
Let’s say you have multiple WebSocket servers, and you want to ensure that only one of them is actively handling session ABC123 at any moment.
A regular Redis lock (e.g., SETNX) works fine on one Redis node, but what if that node goes down or partitions?
Redlock solves that by achieving a consensus-style lock across N Redis nodes.
How It Works
Step-by-step overview (with 5 Redis nodes):
- The client (e.g., your app) gets the current timestamp.
- It sends a SETNX with TTL command (e.g.,
SET resource_name my_random_value NX PX 30000) to all 5 Redis nodes. - If it receives at least 3 successful acknowledgments (majority), it considers the lock acquired.
- The client uses the lock for its critical section (e.g., processing a WebSocket session).
- It releases the lock by deleting the key only if it still owns it (to avoid deleting someone else’s lock).
Notes:
- The random value ensures the lock is unique to the client (to prevent accidental unlocks).
- The TTL (expiration) ensures eventual recovery in case a client crashes while holding the lock.
Why Redlock Instead of Single Redis?
| Problem | Redlock Fix |
|---|---|
| Redis node goes down | Lock still holds if majority of nodes are up |
| Network partitions | Lock held only if majority can be contacted |
| Clock skew | Redlock is time-based but doesn't rely on synchronized clocks |
| Crash during lock | TTL guarantees cleanup |
Libraries That Implement Redlock
- node-redlock (Node.js)
- redis-py with Redlock support (Python)
- Redisson (Java)
- ioredis has compatible utilities
- AWS ElastiCache + Redis also works, but typically you’d need multiple nodes in different AZs
Caveats / Debates
Redlock is sometimes controversial because:
- It’s not a true consensus protocol (like Raft or Paxos),
- It depends on timing assumptions (e.g., that you can acquire the majority of locks within a bounded window),
- Some argue that Redis cluster-mode or centralized locking with etcd/Zookeeper is more predictable.
That said, it’s widely used in practice for soft locks and coordination in distributed systems that tolerate occasional stale lock recovery.
TL;DR
Redis Redlock = a way to get distributed mutual exclusion using multiple Redis instances.
- ✅ Good for coordinating session ownership, distributed job scheduling, etc.
- ✅ Protects against Redis node failure or partition
- ⚠️ Best-effort locking (not a full consensus system)
- 🛠️ Requires careful use of TTLs and random tokens