Distributed Lock Mechanisms and Their Redis Implementations

1 Background

High‑concurrency scenarios in e‑commerce (flash sales, limited‑coupon grabs, ticket booking) cause traffic spikes that can lead to overselling if resources are not properly synchronized; therefore, lock mechanisms are essential.

In single‑process environments, language‑level locks such as Java's synchronized or ReentrantLock are sufficient.

In distributed environments, a distributed lock is required to ensure mutual exclusion across multiple clients and machines.

2 Distributed Lock Implementation Methods

Memcached : Uses the atomic add command to create a lock key only when it does not exist.

Zookeeper : Employs sequential ephemeral nodes to build a lock queue, providing watch‑based blocking until the lock is acquired.

Chubby : Google’s coarse‑grained lock service that solves lock expiration caused by request latency via a sequencer mechanism.

Redis : Implements locks using SETNX (single‑node) or the Redlock algorithm (multi‑node).

The rest of the article focuses on Redis‑based distributed locks.

3 Redis Distributed Lock

3.1 Single‑Node Redis Lock

3.1.1 Using SETNX

The simplest approach sets a lock key with SETNX ; the key name (e.g., lock_resource_id ) uniquely identifies the protected resource, and the lock is released by DEL .

This method suffers from a lock‑timeout problem because SETNX and DEL are not atomic; if the process crashes before releasing, the lock may remain forever.

3.1.2 Using Extended SET Command

To make lock acquisition and expiration atomic, Redis’s SET can be called with NX (set only if key does not exist) and EX 10 (expire after 10 seconds).

However, this still cannot fully prevent premature lock release or accidental deletion when the holder’s execution exceeds the expiration time.

3.1.3 Using Redisson

Redisson provides a high‑level distributed lock that automatically renews the lock before expiration by running a watchdog thread (typically every expireTime/3 ), thus avoiding early release.

It supports various Redis deployment modes (single instance, master‑slave, Sentinel, Cluster) and is widely used in production.

3.2 Multi‑Node Redis Lock – Redlock

Single‑node locks are vulnerable to master‑slave failover because the lock may not be replicated before a failover occurs, leading to multiple clients holding the same lock.

Redlock mitigates this by requiring a majority (N/2+1) of N independent Redis nodes to acquire the lock within a short timeout. The algorithm steps are:

Record the current Unix time in milliseconds.

Attempt to acquire the lock on each node with the same key and a unique value (e.g., UUID) using SET NX EX , respecting a client‑side network timeout.

If a majority of nodes grant the lock and the total acquisition time is less than the lock’s TTL, the lock is considered successful.

The effective TTL is reduced by the acquisition time.

If acquisition fails, release any partial locks on all nodes using a Lua script to ensure atomicity.

Redlock also recommends delaying node restarts longer than the lock TTL to avoid lock loss after crashes.

4 Summary

Distributed lock design balances safety, reliability, and complexity. Redlock offers stronger safety guarantees at the cost of more Redis nodes, while single‑node Redis locks satisfy most practical needs; occasional inconsistencies can be handled manually.