Theory
Distributed Locking: Redis Redlock vs ZK/etcd
📋 Overview
Choosing a distributed locking implementation involves a fundamental trade-off between performance and correctness. Redis Redlock offers high-performance, best-effort locking for AP (Available/Partition-tolerant) systems, while ZooKeeper (ZK) and etcd provide strict, consensus-based locking for CP (Consistent/Partition-tolerant) systems.
🏗️ Core Principles & Characteristics
- Redis Redlock:
- Uses a quorum of independent Redis nodes.
- The client sets a key with a TTL on $N$ nodes; it must succeed on $(N/2 + 1)$.
- Relies on time synchronization and TTLs.
- ZK/etcd Locking:
- Uses a distributed consensus protocol (Zab or Raft).
- Locks are tied to ephemeral nodes or leases.
- Strongly consistent; the system guarantees only one holder exists at any time.
- Fencing Tokens: A monotonic counter used to invalidate delayed requests from previous lock holders.
⚖️ Trade-offs: Pros & Cons
- Redis Redlock:
- Pros: Extremely fast (in-memory), easy to set up if Redis is already in use.
- Cons: Theoretical safety flaws (controversial), sensitive to clock drift and GC pauses.
- ZK/etcd:
- Pros: Bulletproof correctness, built-in session/liveness management.
- Cons: Higher latency (disk I/O and consensus), higher operational overhead.
🌍 Real-World Implementation
- Job Schedulers: Often use Redis locks for "at-most-once" execution where an occasional double-run is acceptable.
- Distributed Databases: Use etcd or ZK for leader election and metadata locking (e.g., Vitess, CockroachDB).
- Inventory Management: High-stakes systems (like airline booking) prefer ZK/etcd to prevent overbooking.
💡 Interview "Gotchas" & Tips
- The Redlock Debate: Be prepared to discuss Martin Kleppmann’s critique of Redlock (clock drift and GC issues) and Antirez’s rebuttal.
- Clock Drift: Explain how Redlock can fail if one node's clock jumps forward, causing a lock to expire prematurely.
- GC Pauses: A classic problem where a process stops, its lock expires, another process grabs it, and the first process resumes thinking it still has the lock.
- When to use which? Rule of thumb: Use Redis for performance/efficiency; use ZK/etcd for correctness/safety.
📐 Suggested Architecture Primitives
- Redis Cluster: For Redlock deployments.
- Raft/Zab Consensus Groups: For ZK/etcd-style locking.
- Lua Scripts: Used in Redis to ensure atomic "check-and-release" (checking the random value before deleting).
Canvas