Theory
Redis Distributed Locks & Redlock
📋 Overview
In a distributed system, traditional language-level locks (like synchronized in Java) are insufficient because they only work within a single process. A Redis Distributed Lock allows multiple independent nodes to coordinate access to a shared resource. While a basic Redis lock is suitable for many use cases, the Redlock algorithm provides a more robust, fault-tolerant locking mechanism for clusters where safety and liveness are paramount.
🏗️ Core Principles & Characteristics
- Mutual Exclusion: At any given moment, only one client can hold the lock.
- Deadlock Prevention: Every lock must have a Time-to-Live (TTL). If a client crashes while holding the lock, it will eventually expire, allowing others to proceed.
- Fencing Tokens: A unique identifier (e.g., a UUID) assigned to the lock holder to ensure that a client doesn't accidentally release a lock that has already timed out and been acquired by another.
- Redlock Algorithm: To acquire a lock in a cluster, a client must successfully set the lock key in a Majority ($N/2+1$) of independent Redis nodes within a specific timeframe.
⚖️ Trade-offs: Pros & Cons
- Pros: Extremely fast (sub-millisecond latency); widely supported; simpler to manage than Zookeeper for basic locking needs.
- Cons: The "STW" Problem: A long "Stop-the-World" GC pause in the application can cause a lock to expire while the client still thinks it holds it. Redlock is controversial among some distributed systems experts (like Martin Kleppmann) due to its reliance on synchronized clocks.
🌍 Real-World Implementation
- Inventory Management: Preventing two users from purchasing the "Last Item" in a flash sale.
- Distributed Cron Jobs: Ensuring that a scheduled task (e.g., "Send Daily Reports") only runs on one worker node in a 10-node cluster.
- Leader Election: A simple way to decide which pod in a Kubernetes deployment should act as the "Primary" for background processing.
- Redisson (Java): A popular library that implements the Redlock algorithm and handles the complex logic of auto-renewal ("Watchdog" pattern).
💡 Interview "Gotchas" & Tips
- Atomic SET: Always use
SET key value NX PX ttl. Never doEXISTSthenSET, as this creates a race condition. - The Unlocking Script: Explain why you use Lua scripts for unlocking. It ensures that you only delete the key if the value matches your unique UUID (preventing you from unlocking someone else's lock).
- Clock Drift: In an interview, mention that Redlock's safety depends on the clock drift between nodes being small compared to the lock TTL.
📐 Suggested Architecture Primitives
- TTL (Time-to-Live): Essential for "Liveness"—ensuring the system doesn't hang forever.
- Watchdog Pattern: A background thread that "renews" the lock TTL as long as the client is still alive and processing.
- Majority Quorum: For Redlock, requiring $3/5$ nodes to acknowledge the lock.
- Fencing Token: An auto-incrementing ID used at the database layer to reject writes from clients holding "stale" locks.
Canvas