Redisson 分布式锁核心机制解析

Redisson 分布式锁（RLock）的可靠性依赖于其三大核心机制：用于保证原子性的 Lua 脚本、用于自动续期的看门狗（Watchdog）以及用于高效等待的发布/订阅（Pub/Sub）模型。本文旨在解析这三个机制的内部工作原理。

一、Lua 脚本与原子性保证

分布式锁的加锁操作包含多个步骤（如 exists、hset、pexpire），必须作为一个原子单元执行。Redisson 通过将这些操作封装到 Lua 脚本中，利用 Redis 服务端原子性执行脚本的特性，来消除并发竞态条件。

核心 tryLock Lua 脚本逻辑：

lua 复制代码

-- KEYS[1]: 锁名
-- ARGV[1]: 锁过期时间
-- ARGV[2]: 锁持有者标识 (uuid:threadId)

if (redis.call('exists', KEYS[1]) == 0) then
    redis.call('hset', KEYS[1], ARGV[2], 1);
    redis.call('pexpire', KEYS[1], ARGV[1]);
    return nil;
end;
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
    redis.call('pexpire', KEYS[1], ARGV[1]);
    return nil;
end;
return redis.call('pttl', KEYS[1]);

二、看门狗（Watchdog）的锁续期机制

为防止因业务执行时间过长导致锁提前过期，Redisson 引入了看门狗机制。

该机制在调用不带 leaseTime 参数的 lock() 方法时被激活。lock() 内部会为 leaseTime 传入 -1，这便是触发看门狗的信号。加锁成功后，若 leaseTime 为 -1，Redisson 会启动一个后台定时任务，负责锁的自动续期。

源码逻辑:

java 复制代码

// RedissonLock.java
private <T> RFuture<T> tryAcquireAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId) {
    if (leaseTime != -1) { // leaseTime 为 -1 是激活看门狗的关键
        return tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
    }
    RFuture<Long> ttlFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime, // 使用默认 30s
            TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);

    ttlFuture.onComplete((ttl, e) -> {
        if (e == null) { // 加锁成功后，调度续期任务
            scheduleExpirationRenewal(threadId);
        }
    });
    return (RFuture<T>) ttlFuture;
}

private void scheduleExpirationRenewal(long threadId) {
    newTimeout(new TimerTask() {
        @Override
        public void run(Timeout timeout) throws Exception {
            RFuture<Boolean> future = renewExpirationAsync(threadId);
            future.onComplete((res, e) -> {
                if (res) { // 续期成功，则在 10s (默认时间的1/3) 后再次执行
                    scheduleExpirationRenewal(threadId);
                }
            });
        }
    }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
}

默认情况下，锁的过期时间为 30 秒，看门狗会每隔 10 秒检查一次，如果锁仍被当前线程持有，就将其过期时间重置为 30 秒。unlock() 操作会取消该续期任务。

三、发布/订阅（Pub/Sub）的高效等待模型

为避免获取锁失败的线程进行无效的循环轮询（busy-polling），Redisson 采用 Redis 的发布/订阅模型实现高效等待。

当线程尝试获取锁失败时，它会订阅一个与锁名相关的特定 Channel，然后在一个客户端的 Semaphore 上阻塞等待。当锁被释放时（unlock），会向该 Channel 发布一条消息。订阅者收到消息后，释放 Semaphore，从而唤醒等待的线程，使其重新尝试获取锁。

源码逻辑:

java 复制代码

// LockPubSub.java - 订阅端
private final Semaphore latch = new Semaphore(0);
private final ChannelFuture subscribeFuture;

// 当收到消息时的回调
@Override
protected void onMessage(String channel, Object msg) {
    if (msg.equals(UNLOCK_MESSAGE)) {
        latch.release(); // 释放信号量，唤醒等待线程
    }
}
public void await() {
    latch.acquire(); // 在信号量上阻塞等待
}

// RedissonLock.java - 等待逻辑
private boolean tryLock(long waitTime, ... ) {
    // ... 尝试加锁失败后 ...
    
    // 1. 订阅解锁 channel
    CompletableFuture<RedissonLockEntry> subscribeFuture = subscribe(getChannelName());
    
    // 2. 在 latch 上等待，waitTime 为超时上限
    boolean acquired = entry.getLatch().tryAcquire(waitTime, unit);
    
    // 3. 取消订阅
    unsubscribe(subscribeFuture);
    
    // 4. 被唤醒后，再次尝试获取锁
    if (acquired) {
        return tryAcquireOnce(...);
    }
    return false;
}

这种事件驱动的模式将等待过程中的资源消耗降至最低，避免了对 Redis 服务器产生不必要的轮询压力。