Distributed Locks

Distributed locks are essential in multi-node systems to ensure only one node performs a critical operation at a time, preventing race conditions. In traditional single-server environments, mutexes or semaphores handle concurrency, but distributed systems pose unique challenges. Multiple service replicas run simultaneously, sharing the same database or resource. Without coordination, two instances might process the same job, double-charge a user, or corrupt shared state.

A classic example is a flash sale with 100 units in stock and 10,000 concurrent requests. Without a lock, overselling occurs. Redis Distributed Lock, or Redlock, is the most common approach, utilizing Redis SET NX EX commands. SET sets a lock key with a unique token and a 10-second expiry time (TTL), ensuring auto-expiry and preventing lock loss due to slow processes. If the lock is acquired, the service proceeds with work. If not, it retries or fails.

Redis's atomic nature and TTL prevent deadlocks from crashed processes. However, clock drift can still cause issues. A unique token is essential to avoid releasing a lock acquired by someone else after TTL expiry. The release lock step involves a Lua script that checks if the stored token matches the current token, deleting the key if they match and returning an error otherwise.

However, distributed locks come with trade-offs. Redis is a single point of failure, mitigated by using Redlock for high availability. Clock drift can cause TTL-based expiry issues, while Redlock remains controversial due to debates between Martin Kleppmann and Antirez. Distributed locks are not suitable for long-held locks; instead, consider using queues for idempotent operations, or implement strong consistency with ZooKeeper and fencing tokens in cases requiring it.