Backend Development 10 min read

Understanding Redis Locks: setnx, Redisson, and RedLock

This article explains how Redis locking works by detailing the setnx command, its modern usage with the SET command and PX expiration, common pitfalls, safe unlocking with unique values and Lua scripts, and introduces Redisson's lock implementations and the RedLock algorithm for distributed environments.

Top Architect
Top Architect
Top Architect
Understanding Redis Locks: setnx, Redisson, and RedLock

Redis locks are a frequent topic in distributed systems, and the most common terms are setnx , RedLock , and Redisson . Although many refer to SETNX , the modern practice is to use the SET command with the NX flag and an expiration (e.g., PX 30000 ) to avoid deadlocks when a process crashes.

The SET syntax looks like:

SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL]

When acquiring a lock, a unique client identifier (UUID) should be stored as the value, and unlocking must verify this identifier before deleting the key to prevent accidental release of another process's lock.

Typical unlocking code (non‑atomic) looks like:

String uuid = xxxx;
// acquire lock
set Test uuid NX PX 3000
try {
    // business logic
} finally {
    if (uuid.equals(redisTool.get('Test'))) {
        redisTool.del('Test');
    }
}

Because the GET and DEL operations are not atomic, a safer approach is to use a Lua script that checks the value and deletes the key in a single step:

if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end

Redisson, a Java Redis client, provides high‑level lock APIs that internally use such Lua scripts, offering features like re‑entrant locks, distributed atomic counters, and support for various Redis deployment modes (single, master‑slave, sentinel, cluster).

Beyond simple locks, Redisson also implements the RedLock algorithm, an official Redis distributed lock design that requires a majority of independent Redis instances to acquire the lock. The algorithm works by requesting locks on multiple nodes, ensuring the total acquisition time is less than the lock’s TTL, and releasing the lock on all nodes.

While RedLock improves fault tolerance, it still cannot guarantee 100 % safety; careful timeout configuration and fallback mechanisms are necessary. The article concludes that no locking strategy is perfect, and developers should combine robust code with operational monitoring and manual compensation when needed.

Backend DevelopmentRedisDistributed LockRedissonRedlockSETNX
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.