Redis Distributed Lock Implementation: Design, Issues, and Lessons Learned

The author introduces the motivation for using distributed locks when moving from monolithic JVM applications to distributed systems, where traditional JVM locks no longer work, and mentions Redis and Zookeeper as common cross‑JVM lock providers.

Lock acquisition analysis explains the original design that relied on manual key‑expiration checks because early Redis versions lacked SET ... NX PX support, and describes why GETSET is used instead of a simple SET to avoid race conditions when multiple clients attempt to acquire the lock after expiration.

Q&A highlights:

Why not use

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

? – because the feature was unavailable before Redis 2.6.12.

Why use GETSET after detecting expiration? – to ensure only one client successfully overwrites the stale lock value.

Lock release analysis shows that simply deleting the key can be unsafe if the lock holder crashes and another client acquires the lock; therefore the release process first checks whether the stored value is still valid before performing DEL.

Q&A on release:

Why check expiration before deletion? – to prevent a delayed client from deleting a lock that another client currently holds.

The article then reflects on the shortcomings of the current implementation, such as the two‑step release that can still suffer from race conditions, and mentions that Lua scripts could provide an atomic solution.

Further questions address lock renewal (the current implementation lacks automatic renewal, and a library like Redisson could solve it) and high‑availability. The author describes a failover mechanism that writes to multiple Redis nodes, but notes that non‑atomic multi‑write can still cause duplicate lock acquisition under network partitions.

Finally, the author acknowledges these design flaws, suggests possible improvements (e.g., using Lua scripts, Redisson, or database unique indexes), and invites constructive discussion.