Implementing Distributed Locks with Redisson

Redisson Implementing Distributed Lock

This article introduces the principles behind Redisson's distributed lock implementation, focusing on its three main modules: lock mechanism, watchdog auto‑extension, and Lua script usage.

1. Efficient Distributed Lock Design

When designing a distributed lock, several essential requirements must be considered:

Mutual Exclusion

Only one thread should hold the lock at any given time under high concurrency.

Deadlock Prevention

Locks should have an effective time to ensure they are released automatically if a thread crashes, avoiding deadlocks.

Performance

Lock granularity and scope should be minimized to reduce wait time and avoid blocking many threads.

Specifically:

Keep lock granularity as small as possible , e.g., lock by product ID rather than a generic name.

Limit the lock scope to the smallest code region necessary.

2. Redisson Principle Analysis

Redisson satisfies the above requirements. The lock acquisition works as follows:

Lock Mechanism

Threads attempt to acquire the lock; on success they execute a Lua script to store data in Redis. On failure they repeatedly try in a loop until successful.

Watchdog Auto‑Extension

If a thread holding a lock crashes, the lock will automatically expire after its set TTL (default 30 seconds). The watchdog thread can extend the lock's TTL while the business logic is still running, but it adds overhead and is disabled by default.

//设置锁1秒过去
            redissonLock.lock("redisson", 1);
            /**
             * 业务逻辑需要咨询2秒
             */
            redissonLock.release("redisson");

          /**
           * 线程1 进来获得锁后，线程一切正常并没有宕机，但它的业务逻辑需要执行2秒，这就会有个问题，在 线程1 执行1秒后，这个锁就自动过期了，
           * 那么这个时候 线程2 进来了。那么就存在 线程1和线程2 同时在这段业务逻辑里执行代码，这当然是不合理的。
           * 而且如果是这种情况，那么在解锁时系统会抛异常，因为解锁和加锁已经不是同一线程了，具体后面代码演示。
           */

Why Use Lua Scripts?

Lua scripts ensure atomic execution of complex business logic on Redis, which is single‑threaded.

Reentrant Lock Mechanism

Redisson achieves reentrancy because:

1、Redis stores lock data as a Hash type
2、The Hash key contains the current thread information.

The stored hash looks like <key,<key1,value>> , where the key is "redisson" and the value includes a GUID plus the thread ID, enabling the same thread to reacquire the lock without blocking.

Redis Distributed Lock Drawbacks

In Redis Sentinel or master‑slave setups, if the master fails during lock acquisition, a slave may become the new master and allow another client to acquire the same lock, leading to duplicate locks and potential data corruption.

This article is based on the author’s development experience and publicly available resources.