02 分布式锁隐患及锁续期原理

在高并发场景下，Redis分布式锁可能存在哪些隐患？您项目中如何实现锁的自动续期？如果采用Redisson框架，其看门狗机制的实现原理是什么？

Redis分布式锁的隐患
热key问题导致单节点压力（可通过分片或分区锁缓解）。
锁超时与业务执行冲突：若业务执行时间超过锁超时时间（TTL），导致锁自动释放后其他线程获取锁，可能引发数据竞态。
客户端故障导致死锁：若客户端崩溃未释放锁，需依赖TTL自动过期（Redisson通过看门狗解决）。
锁误删风险：非原子操作释放锁（如先get再del）可能导致删除其他客户端的锁，应使用Lua脚本保证原子性。
集群脑裂问题：主从切换时可能导致多个客户端持有锁（需用RedLock等算法缓解）。

自动续期实现
✅ 正确：Redisson通过看门狗机制自动续期。
🔧 实现细节：
当获取锁不指定leaseTime时，看门狗生效（默认TTL 30秒）。
续期间隔为TTL的1/3（即10秒），通过internalLockLeaseTime参数控制。
续期逻辑在org.redisson.RedissonLock#renewExpiration中实现，使用Timeout定时任务。

看门狗机制原理
❌ 修正：非时间轮算法，而是基于Netty的HashedWheelTimer（时间轮的一种实现）调度定时任务。
🔍 核心流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

private void renewExpiration() {
    Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
        @Override
        public void run(Timeout timeout) {
            // 异步续期操作
            RFuture<Boolean> future = renewExpirationAsync(threadId);
            future.onComplete((res, e) -> {
                if (e != null) {
                    // 异常处理
                    return;
                }
                if (res) {
                    // 递归调用继续续期
                    renewExpiration();
                }
            });
        }
    }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS); // 10秒后执行
}

关键点：

• 每次续期成功后递归调用，形成链式续期。
• 释放锁时调用cancelExpirationRenewal取消Timeout任务。
• 依赖Netty的单线程时间轮调度，避免频繁创建线程

Redisson额外优化

• 可重入锁：通过客户端ID+线程ID实现，避免同一线程重复获取锁的阻塞。
• 订阅解锁事件：等待锁的线程通过Redis的pub/sub订阅锁释放事件，而非盲目重试，减少Redis压力