Mastering Distributed Locks with Redis: From Basics to RedLock

What is a Distributed Lock?

Locks are everywhere in daily life; in computing a lock controls access to shared resources. A distributed lock extends this concept to multiple processes on different machines competing for the same resource.

Key Characteristics of a Good Distributed Lock

Mutual exclusion : only one contender holds the lock at a time.

Safety : the lock must be released even if the holder crashes.

Symmetry (re‑entrancy) : the same client that acquires the lock must be the one that releases it.

Reliability : the lock should survive failures and network issues.

Basic Implementation with Redis

The simplest approach uses SETNX key value. If the key does not exist, it is created and the command returns 1; otherwise it returns 0. Lock acquisition is done with SETNX, and release with DEL key.

Adding Expiration

To avoid dead locks when a client crashes, an expiration time is needed. The atomic command SET key value NX EX seconds combines lock acquisition and timeout.

Owner Identifier

Include a unique owner ID in the value so that only the client that set the lock can delete it, preventing one client from releasing another’s lock.

Lua for Atomic Check‑and‑Delete

Checking the owner and deleting the lock must be atomic. A small Lua script executed by Redis can perform both steps safely.

Ensuring Reliability

Beyond the basic lock, we must consider failure scenarios such as Redis node crashes, network partitions, and clock drift.

Disaster Recovery

Use master‑slave replication with Sentinel or a multi‑node RedLock algorithm. In RedLock, a client must obtain the lock on a majority of N independent Redis instances (e.g., 3 out of 5) to consider the lock acquired.

RedLock under NPC Challenges

Network delay, process pause (GC), and clock drift can still cause lock inconsistencies even with RedLock. Therefore, a distributed lock can never be absolutely reliable; it must be combined with idempotent business logic.

Takeaways

Redis‑based distributed locks can satisfy most practical requirements when built with mutual exclusion, safety, symmetry, and reliability in mind. However, developers should avoid over‑reliance on the lock itself and design services to tolerate occasional lock failures.