Redis Redlock is a distributed locking algorithm proposed by Redis creator Salvatore Sanfilippo (antirez).

It’s used to implement distributed locks safely in environments where you have multiple Redis instances (to avoid single point of failure).

---

🔹 Problem Redlock Solves

Imagine you want a lock (like a mutex) across multiple servers so that only one process at a time can access a shared resource (e.g., a file, payment transaction, inventory update).

• If you use a single Redis instance with SETNX for locking, the lock works but Redis itself can fail (crash, restart, partition).
• To improve reliability, you replicate Redis or run it in a cluster. But replication itself is not strongly consistent (it’s asynchronous), so you might get lock inconsistencies.

👉 That’s why Redlock exists – to provide a safer, fault-tolerant distributed lock.

---

🔹 How Redlock Works (Step by Step)

Suppose you have N Redis masters (recommended: 5 for safety).

1. Get timestamps – Client notes the current time in milliseconds.

2. Try acquiring the lock in all Redis nodes

   • Use the command:

     SET resource_name unique_value NX PX 30000
     

     • NX → set only if not exists (ensures lock).
     • PX 30000 → lock expires automatically in 30s (avoid deadlocks).
     • unique_value → random value (UUID) so only lock owner can release.

3. Check how many locks were acquired

   • Client must succeed in at least (N/2 + 1) nodes (majority quorum).

4. Calculate validity time

   • Actual lock validity = lock expiration time − time already spent acquiring.
   • If validity > 0 and quorum achieved → lock is acquired.

5. If lock not acquired

   • Release any acquired locks and retry after a random delay (to avoid collisions).

---

🔹 Releasing the Lock

Only the client that set the lock can release it. It uses a Lua script (to check unique value before deleting):

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

This ensures no one else can delete your lock.

---

🔹 Why Redlock Is Safer

• Works across multiple Redis instances.
• Tolerates failures (you still succeed if most Redis nodes are alive).
• Uses auto-expiry to avoid deadlocks if a client crashes.
• Uses quorum (majority voting) like consensus algorithms.

---

🔹 When to Use Redlock

✅ Best for distributed systems where:

• Multiple servers/processes need synchronized access.
• You want high availability (not relying on a single Redis instance).

• Example:

  • Preventing two users from buying the last item in stock.
  • Ensuring only one service runs a scheduled job at a time.

---

👉 In short: Redis Redlock is a distributed locking algorithm built on top of Redis to safely implement locks across multiple Redis nodes, ensuring fault-tolerance and avoiding race conditions.

---

Let’s compare Redis Redlock with Zookeeper locks (via Curator recipes) — both are widely used in distributed systems for coordination and locking.

---

🔹 1. Core Idea

• Redis Redlock → Uses multiple independent Redis instances (usually 3 or 5) and a quorum-based algorithm for distributed locking.
• Zookeeper Lock (Curator) → Uses Zookeeper’s strong consistency (ZAB protocol) to implement locks using ephemeral sequential znodes.

---

🔹 2. How Lock Works

✅ Redis Redlock

• Client sets a lock key in multiple Redis nodes (SET key value NX PX).
• Needs quorum (majority) to consider lock acquired.
• Lock expires automatically after TTL (auto-expiry).
• Relies on time-based validity (lock may expire if client is too slow).

✅ Zookeeper Lock (Curator)

• Client creates an ephemeral sequential znode in a lock path.
• The client with the lowest sequence number holds the lock.
• Others watch the previous znode and wait until it disappears.
• Strongly consistent: if you see you hold the lock, no one else does.

---

🔹 3. Consistency Model

• Redis Redlock → Provides eventual consistency.

  • Redis replication is asynchronous, so under rare network splits, two clients may think they both acquired a lock.

• Zookeeper → Provides strong consistency (CP system in CAP theorem).

  • Only one client can ever hold the lock at a time, guaranteed by quorum and leader election.

---

🔹 4. Failure Handling

• Redis Redlock:

  • If client crashes → lock auto-expires after TTL (avoids deadlock).
  • But lock can expire while the client still works → another process may acquire prematurely.

• Zookeeper:

  • If client crashes → ephemeral znode is deleted automatically (lock released).
  • No premature expiry — lock is explicitly released or lost only if client session dies.

---

🔹 5. Performance

• Redis Redlock:

  • Very fast (in-memory).
  • Suitable for low-latency, high-throughput workloads.

• Zookeeper:

  • Slower (disk persistence + quorum).
  • More overhead per operation.
  • Suitable for critical correctness over performance.

---

🔹 6. Typical Use Cases

✅ Redis Redlock

• Lightweight distributed coordination.
• Non-critical correctness (occasional duplicate execution acceptable).

• Examples:

  • Background job scheduling (only one worker should run a job).
  • Preventing duplicate transactions temporarily.
  • Inventory updates (with retries).

✅ Zookeeper Lock (Curator)

• Strong correctness required.
• Leader election, service discovery, configuration management.

• Examples:

  • Only one master node in a cluster.
  • Distributed databases ensuring strict ordering.
  • Financial transactions where duplicates are unacceptable.

---

🔹 7. Summary Table

Feature	Redis Redlock 🚀	Zookeeper Lock 🔒
Consistency	Eventual	Strong (linearizable)
Fault Tolerance	Good (multi-node)	Very strong
Performance	Very fast (in-memory)	Slower (disk + quorum)
Auto-expiry	Yes (via TTL)	No (ephemeral node release)
Ease of Setup	Simple (Redis already in infra)	Complex (needs Zookeeper ensemble)
Use Case Fit	High-performance but “best effort” locking	Strict correctness required

---

👉 Rule of Thumb:

• Use Redis Redlock when:

  • Speed matters.
  • Occasional duplicate execution is acceptable.
  • Example: job schedulers, cache invalidation.

• Use Zookeeper (Curator) when:

  • Correctness > Performance.
  • Duplicate work is unacceptable.
  • Example: cluster leader election, financial systems, strict ordering.

---

🔹 Etcd Locks (Overview)

Etcd is a distributed key-value store (backed by the Raft consensus algorithm) widely used in Kubernetes for storing cluster state. It also provides distributed coordination primitives, including locks, through its gRPC API.

Etcd locks are typically implemented with the Etcd concurrency package:

• You create a lease (a TTL-bound session).
• Lock acquisition = writing a key under a prefix using a lease.
• If the client holding the lease disconnects or crashes → lease expires → lock is auto-released.
• Etcd guarantees strong consistency via Raft (no two clients can hold the lock simultaneously).

---

🔹 Comparison: Redis Redlock vs Zookeeper vs Etcd

Feature / Aspect	Redis Redlock 🚀	Zookeeper 🔒	Etcd 🔑
Consistency Model	Eventual (AP-ish)	Strong (CP)	Strong (CP via Raft)
Lock Mechanism	Keys with TTL & quorum	Ephemeral sequential znodes	Lease-based locks with sessions
Auto-expiry	Yes (TTL on keys)	Yes (ephemeral node disappears)	Yes (lease expiry)
Failure Handling	Lock may expire early while client still works	Lock released only if session dies	Lock released only if lease expires
Performance	Very fast (in-memory)	Medium (disk + quorum writes)	Medium (quorum via Raft, slower than Redis)
Ease of Setup	Easiest (Redis is common)	More complex (needs ensemble)	Medium (etcd cluster, but Kubernetes already uses it)
Typical Use Cases	Lightweight job scheduling, cache invalidation	Leader election, strict coordination	Kubernetes leader election, cluster metadata, distributed consensus
Correctness Guarantees	“Best effort” (may allow duplicates in rare cases)	Very strong	Very strong
CAP Theorem	AP-ish (availability focus)	CP (consistency focus)	CP (consistency focus)

---

🔹 Real-World Usage

✅ Redis Redlock

• Good when latency matters and absolute correctness is not critical.

• Examples:

  • Distributed cron jobs (only one worker should run).
  • Avoiding cache stampede.
  • Rate limiting (with some tolerance for error).

✅ Zookeeper

• Designed for strict coordination in distributed systems.

• Examples:

  • Hadoop, Kafka use it for leader election.
  • Cluster membership management.
  • Scenarios where two clients holding a lock simultaneously is unacceptable.

✅ Etcd

• Default choice in Kubernetes and cloud-native environments.

• Examples:

  • Kubernetes leader election for controllers.
  • Cluster metadata synchronization.
  • Any system that already depends on Etcd for consensus.

---

🔹 Rule of Thumb (When to Choose)

• Redis Redlock → If you already have Redis, need fast locks, and can tolerate rare correctness issues.
• Zookeeper → If you need bulletproof correctness, don’t mind complexity, and your system is not ultra-latency sensitive.
• Etcd → If you’re in the cloud-native / Kubernetes world, you already have Etcd, and want correctness with simpler APIs than Zookeeper.

---

👉 So you can think of it like this:

• Redis Redlock = Fast & lightweight (best effort)
• Zookeeper = Heavy but strict (enterprise-grade correctness)
• Etcd = Cloud-native strong consistency (modern alternative to Zookeeper)

---