Understanding Redis Distributed Locks: setnx, Redisson, and RedLock

Redis distributed locking commonly involves three terms: setnx, RedLock, and Redisson. The setnx concept actually refers to using the SET command with the NX option, e.g.: SET key value [EX seconds|PX milliseconds] [NX|XX] [KEEPTTL] To avoid deadlocks, a timeout (e.g., PX 30000) is set so that a crashed process does not hold the lock indefinitely.

When releasing a lock, the value stored (often a UUID or client ID) should be checked before deletion. A typical Java‑style pseudocode is:

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

However, GET and DEL are not atomic, which can still cause race conditions. An atomic solution uses a Lua script executed via EVAL:

-- lua delete lock<br/>-- KEYS[1] = lock key, ARGV[1] = expected UUID<br/>if redis.call('get', KEYS[1]) == ARGV[1] then<br/>    return redis.call('del', KEYS[1])<br/>else<br/>    return 0<br/>end

Before Redis 2.6.12, locks were implemented with two commands ( SETNX + EXPIRE), which was not atomic. Modern Redis supports the combined SET with NX and expiration, simplifying lock code.

Redisson, a Java Redis client, provides high‑level lock APIs (e.g., RedissonLock) that internally use Lua scripts for atomic lock/unlock operations, supporting re‑entrancy and distributed lock features.

RedLock is a Redis‑official distributed lock algorithm that requires a majority of independent Redis instances to acquire the lock. The algorithm succeeds if at least (N/2)+1 nodes grant the lock within the lock’s TTL.

Despite these mechanisms, no solution guarantees 100 % safety; developers should still implement compensating actions for edge cases.