Mastering Redis Distributed Locks: From SETNX to RedLock and Redisson

SETNX and Redis Locks

When people mention a Redis lock, the most common terms are SETNX , RedLock and Redisson .

SETNX vs SET with NX

The command most people refer to as SETNX key value is actually the SET command with the NX option. The full syntax is:

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

Because the SET command supports many options, the original SETNX command is considered legacy.

To make a lock reliable, a timeout is added with PX 30000 (30 seconds). Without a timeout, a process that crashes while holding the lock would leave the key forever, preventing other clients from acquiring the lock.

Atomic Unlock with Lua

A common pattern is to store a unique client identifier (e.g., a UUID) as the lock value and, when releasing, compare the stored value with the current client’s identifier before deleting the key. The pseudo‑code is:

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

However, GET and DEL are not atomic, which can still cause race conditions.

Using a Lua script guarantees atomicity because the script is executed as a single Redis command:

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

Redisson and Advanced Lock Implementations

Redisson is a Java Redis client that provides high‑level APIs for distributed locks, atomic counters, and more. Its lock implementation ( RedissonLock ) uses Lua scripts internally to ensure atomic lock acquisition and release.

Redisson also implements the RedLock algorithm, which is a distributed lock protocol proposed by the Redis author. RedLock requires a majority of Redis instances (N/2 + 1) to acquire the lock and releases the lock on all instances.

RedLock Algorithm Steps

Attempt to acquire the lock on each Redis node sequentially.

Skip nodes that do not respond within the configured timeout.

If a majority of nodes (e.g., three out of five) acquire the lock within the lock’s TTL, consider the lock obtained.

When releasing, delete the lock key on all nodes.

The algorithm assumes that the total time spent acquiring the lock is less than the lock’s TTL; otherwise the lock is considered failed.

Practical Considerations

Even with RedLock, a 100 % guarantee of safety is impossible; additional application‑level compensation may be required.