Redis Distributed Lock: SETNX, Redlock, and Redisson

A minimum correct Redis lock uses SET key uniqueValue NX PX 30000. NX makes the set atomic "only if absent", PX sets an expiration so a crashed client can't hold the lock forever, and uniqueValue — typically a UUID per client — lets only the owner release it. Release must be atomic: you can't GET and then DEL, because the lock could have expired and been reacquired by another client between those two calls, and then you'd delete their lock. The standard solution is a Lua script that checks value equality and deletes in one atomic step. The harder problem is expiration vs business time. If I set the TTL to 30s and my job takes 35s, the lock expires at 30s, another worker acquires it, and now two workers are both running the critical section. The fix is a watch-dog — a background thread that extends the TTL periodically (say every 10s, TTL stays 30s) for as long as the business logic is still running. This is exactly what Redisson's RLock does by default. For reentrancy, you store a counter keyed by thread ID — Redisson uses a Redis hash where the field is "threadId:lockName" and the value is the reentry count, incrementing on re-acquisition and decrementing on release, only deleting the key when the count hits zero. For high availability, the Redlock algorithm acquires on a majority of N independent Redis masters within a bounded time window, handling single-node failures. Redlock is debated — Martin Kleppmann pointed out that a long GC pause on the client can let a competitor acquire the lock before the original client realizes it lost ownership. For strict correctness, you need a fencing token — a monotonically increasing number returned on acquire that the downstream storage uses to reject stale writers. For most business use cases, a single-node Redis with watch-dog and atomic release is more than good enough.