Redisson 分布式锁的实现原理

Redisson 分布式锁的实现原理是 Redis 分布式锁的。

拾忆，想起

1031人浏览 · 2025-09-11 06:30:00

拾忆，想起 · 2025-09-11 06:30:00 发布

Redisson 分布式锁的实现原理是 Redis 分布式锁的工业级解决方案，它通过组合 Redis 特性 + 守护线程 + 重入机制，解决了原生分布式锁的三大痛点：原子性、死锁、可重入。其核心设计如下：

一、加锁原理（核心 Lua 脚本）

-- 参数：KEYS[1]=锁名称, ARGV[1]=锁超时时间, ARGV[2]=客户端ID
if redis.call('exists', KEYS[1]) == 0 then
    -- 锁不存在：创建Hash结构，记录客户端ID和重入次数
    redis.call('hincrby', KEYS[1], ARGV[2], 1) 
    -- 设置锁过期时间
    redis.call('pexpire', KEYS[1], ARGV[1]) 
    return 1 -- 加锁成功
end
-- 锁已存在且是当前客户端持有：重入次数+1
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 1 
end
return 0 -- 加锁失败（锁被其他客户端持有）

二、核心机制图解

在这里插入图片描述

三、六大核心技术

1. 可重入锁设计

存储结构：Hash 类型 lock_key: { client_id: count }
重入计数：同一线程多次加锁时 count++
释放规则：解锁时 count--，归零后删除 key

// Java 示例：重入锁使用
RLock lock = redisson.getLock("order_lock");
lock.lock();  // 首次加锁
try {
    lock.lock(); // 重入加锁（计数+1）
    // 业务代码...
} finally {
    lock.unlock(); // 释放一层（计数-1）
    lock.unlock(); // 计数归零，彻底释放
}

2. 看门狗机制（解决死锁）

后台线程：加锁成功后启动守护线程
续期逻辑：每 10s（默认）检查锁是否存在，存在则重置过期时间为 30s

续期源码：

// Redisson 看门狗核心逻辑
private void scheduleExpirationRenewal(String threadId) {
    // 每隔10秒执行续期
    timeout.set(executor.schedule(() -> {
        if (redisClient.eval(...) == 1) { // 检查是否仍持有锁
            // 重置过期时间为30秒
            redisClient.expire(lockName, 30); 
            scheduleExpirationRenewal(threadId); // 递归调用续期
        }
    }, 10, TimeUnit.SECONDS)); // 间隔时间
}

3. 锁续期流程

在这里插入图片描述

4. 解锁的原子性

-- 解锁Lua脚本（保证原子性）
if redis.call('hexists', KEYS[1], ARGV[1]) == 0 then 
    return nil -- 锁不存在或不属于当前客户端
end 
local counter = redis.call('hincrby', KEYS[1], ARGV[1], -1) 
if counter > 0 then 
    redis.call('pexpire', KEYS[1], ARGV[2]) -- 重入计数-1
    return 0 
else 
    redis.call('del', KEYS[1]) -- 计数归零，删除锁
    return 1 
end

5. 锁竞争处理（自旋 + 订阅机制）

自旋尝试：未获取锁时短暂休眠后重试
Pub/Sub 订阅：监听锁释放事件，避免无效轮询

在这里插入图片描述

6. 锁类型扩展

锁类型	特点	适用场景
公平锁	按申请顺序分配锁	需要严格顺序的执行
联锁（MultiLock）	同时锁定多个资源	分布式事务场景
红锁（RedLock）	多Redis实例投票	高可靠性要求（金融场景）
读写锁	分离读/写操作	读多写少场景

四、对比原生 SETNX 方案

能力	原生 SETNX	Redisson
可重入性	❌ 不支持	✅ 基于Hash结构实现
锁续期	❌ 需业务代码实现	✅ 看门狗自动续期
锁释放原子性	❌ 需Lua脚本	✅ 内置Lua脚本保证
锁竞争优化	❌ 轮询消耗资源	✅ Pub/Sub订阅减少轮询
锁类型	❌ 仅基础锁	✅ 公平锁/联锁/读写锁
客户端宕机处理	⚠️ 依赖过期时间	✅ 看门狗停止即释放

五、红锁（RedLock）原理

在这里插入图片描述

红锁算法步骤：

获取当前毫秒级时间戳 T1
向 N 个 Redis 实例顺序发起加锁请求
计算获取锁总耗时 T2-T1（要求 < 锁超时时间)
当 成功实例数 >= N/2+1 且 总耗时 < 锁超时时间 时加锁成功
否则向所有实例发起解锁请求

六、最佳实践

// 正确使用示例
RLock lock = redisson.getLock("resource_lock");
try {
    // 尝试获取锁，等待10秒，锁超时自动释放时间为30秒
    boolean acquired = lock.tryLock(10, 30, TimeUnit.SECONDS);
    if (acquired) {
        // 业务逻辑...
    }
} finally {
    if (lock.isLocked() && lock.isHeldByCurrentThread()) {
        lock.unlock();
    }
}