Mastering Redis Locks: From SETNX to RedLock and Redisson

Introduction

Redis is often used for distributed locking. The most common terms are SETNX, RedLock, and Redisson.

SETNX

In practice, SETNX usually refers to the SET key value NX command, which supports many optional parameters:

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

The lock works because the key is set only when it does not already exist; if process A holds the lock, process B cannot acquire it.

Adding an expiration (e.g., PX 30000) prevents a dead lock if the owning process crashes.

However, simply checking the value and then deleting the key is not atomic, leading to race conditions.

To guarantee atomicity, a Lua script can be used:

-- Lua script to delete lock only if the value matches
if redis.call('get', KEYS[1]) == ARGV[1] then
    return redis.call('del', KEYS[1])
else
    return 0
end

This script ensures that the get‑and‑del operation is executed as a single command.

Redisson

Redisson is a Java Redis client that provides high‑level APIs, including distributed implementations of JUC classes such as AtomicLong. Its lock implementation ( RedissonLock) uses Lua scripts internally for atomic lock acquisition and release.

RedLock

RedLock is an algorithm proposed by the Redis authors for distributed locks across multiple independent Redis instances. It requires a majority (N/2+1) of nodes to acquire the lock within a timeout. The algorithm accounts for network latency and node failures.

Request lock on multiple nodes sequentially.

Skip nodes that exceed a predefined timeout.

If a majority of nodes acquire the lock within the lock’s TTL, consider the lock obtained.

Release the lock on all nodes when done.

Because the lock’s effective TTL is reduced by the time spent acquiring it on successful nodes and by the time waiting on failed nodes, the actual usable period is shorter than the configured expiration.

Both SETNX‑based locks and RedLock have limitations and cannot guarantee 100% safety; additional compensating mechanisms are often required.

Conclusion

No locking strategy can provide absolute stability; developers should combine proper lock implementations with fallback and compensation logic.