Redis分布式锁三种实现：setnx、Lua脚本与Redisson详解

来源：互联网 2026-07-24 09:09:10

分布式锁，在分布式系统里是个绕不开的话题——多个节点同时访问共享资源，总得有个协调机制。Redis凭借高性能和原子操作，成了实现分布式锁的主流选择。下面从原理层面拆解Redis分布式锁的核心逻辑，再详细分析三种常见实现方式的代码、优缺点，以及生产环境里要特别注意的地方。一、Redis分布式锁核心原

分布式锁，在分布式系统里是个绕不开的话题——多个节点同时访问共享资源，总得有个协调机制。Redis凭借高性能和原子操作，成了实现分布式锁的主流选择。下面从原理层面拆解Redis分布式锁的核心逻辑，再详细分析三种常见实现方式的代码、优缺点，以及生产环境里要特别注意的地方。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

一、Redis分布式锁核心原理

1.1 核心设计目标

一个可靠的分布式锁，得满足以下几个特性：

互斥性：同一时刻只允许一个客户端持有锁，否则并发操作共享资源，数据很容易乱掉；
安全性：锁只能由持有它的客户端释放，不能被其他客户端误删；
超时释放：万一持有锁的客户端宕机了，锁不能永久不释放，要能自动过期，避免死锁；
原子性：加锁、释放锁的关键操作必须原子执行，否则并发场景下很容易出逻辑漏洞；
可重入（可选）：同一个客户端持有锁后，再次请求同一把锁时不用重新获取，能提升易用性。

1.2 Redis实现锁的核心基础

Redis依靠下面这几个核心命令来支撑分布式锁：

命令/特性	作用
`SET key value NX EX t`	原子执行“不存在则设置（NX）+ 过期时间（EX）”，避免加锁与设超时拆成两步操作
`DEL key`	删除锁（释放锁），需要配合校验锁归属，否则可能误删别人的锁
Lua脚本	将“校验锁归属+释放锁”封装成一个原子操作，解决释放锁时的并发安全问题
Redisson（客户端）	基于Redis封装了可重入、自动续期、公平锁等高级特性，大大简化了锁的使用

二、三种实现方式详解（逻辑+问题分析）

方式1：基础实现（SetNX + 手动校验释放）

2.1 代码逻辑拆解

@Resource
private StringRedisTemplate stringRedisTemplate;

/**
 * 示例：扣减库存（基础分布式锁实现）
 */
private void order(){
    // 1. 生成唯一锁值（用于校验锁归属，避免误删）
    String lockValue = UUID.randomUUID().toString();
    // 2. 加锁：SETNX + 过期时间（原子操作），30秒自动释放
    Boolean locked = stringRedisTemplate.opsForValue()
            .setIfAbsent("product:1001:lock", lockValue, 30, TimeUnit.SECONDS);
    try {
        // 3. 加锁成功则执行业务逻辑（扣减库存）
        if (locked) {
            Integer count = (Integer) stringRedisTemplate.opsForHash().get("product:1001",
"number");
            if (count > 0) {
                stringRedisTemplate.opsForHash().put("product:1001", "number", count - 1);
            }
        }
    } finally {
        // 4. 释放锁：先校验锁归属，再删除（非原子操作）
        if (lockValue.equals(stringRedisTemplate.opsForValue().get("product:1001:lock"))) {
            stringRedisTemplate.delete("product:1001:lock");
        }
    }
}

2.2 核心逻辑

加锁：通过setIfAbsent（底层就是SET NX EX）实现原子加锁，同时设置30秒超时，万一客户端宕机，锁也会自动释放，避免死锁；
锁归属校验：用UUID生成唯一的lockValue，释放锁前校验值是否匹配，防止误删其他客户端的锁；
释放锁：在finally块中执行释放逻辑，确保业务执行完（或抛异常）后把锁释放掉。

2.3 存在的核心问题

释放锁非原子性：“校验锁归属 + 删除锁”是两步操作，如果校验后锁恰好过期，此时其他客户端已经加上了新锁，当前客户端再执行delete就会把别人的锁给删掉；
无重试机制：加锁失败直接放弃，实际场景中需要根据业务设置重试逻辑（比如循环重试加休眠）；
无锁续期：如果业务执行时间超过30秒，锁会自动过期，导致多个客户端同时执行业务，互斥性就被破坏了；
Hash操作类型转换风险：stringRedisTemplate.opsForHash().get()返回的是Object，强转Integer很可能出现类型异常（所以一定要先判空再加类型校验）。

方式2：优化版（Lua脚本保证释放锁原子性）

2.1 代码逻辑拆解

@Resource
private StringRedisTemplate stringRedisTemplate;

private static final String LOCK_KEY = "product:1001:lock";
private static final String STOCK_KEY = "product:1001:number";
private static final long LOCK_TIMEOUT = 30; // 锁超时时间（秒）
private static final long SLEEP_TIME = 100;  // 重试间隔（毫秒）

private void order() {
    String lockValue = UUID.randomUUID().toString();
    try {
        // 1. 尝试获取锁（原子加锁）
        Boolean locked = tryAcquireLock(lockValue);
        if (!locked) {
            // 加锁失败可重试/返回失败（示例直接返回，实际可加循环重试）
            return;
        }
        // 2. 执行业务：获取并扣减库存（简化为String结构，避免Hash类型转换问题）
        String stockStr = stringRedisTemplate.opsForValue().get(STOCK_KEY);
        if (stockStr == null || Integer.parseInt(stockStr) <= 0) {
            return;
        }
        stringRedisTemplate.opsForValue().set(STOCK_KEY, String.valueOf(Integer.parseInt(stockStr) - 1));
    } finally {
        // 3. 释放锁：Lua脚本封装“校验+删除”，保证原子性
        releaseLock(lockValue);
    }
}

/**
 * 原子加锁：SET NX EX
 */
private Boolean tryAcquireLock(String lockValue) {
    return stringRedisTemplate.opsForValue()
            .setIfAbsent(LOCK_KEY, lockValue, LOCK_TIMEOUT, TimeUnit.SECONDS);
}

/**
 * 原子释放锁：Lua脚本
 */
private void releaseLock(String lockValue) {
    String script = "if redis.call('get', KEYS[1]) == ARGV[1] then " +
            "return redis.call('del', KEYS[1]) " +
            "else " +
            "return 0 " +
            "end";
    stringRedisTemplate.execute(
            new DefaultRedisScript<>(script, Long.class),
            Arrays.asList(LOCK_KEY),
            lockValue
    );
}

2.2 核心优化点

释放锁原子化：将“校验锁归属（get）+ 删除锁（del）”封装成Lua脚本，Redis会原子执行整个脚本内容，彻底解决方式1中的“误删锁”问题；
简化库存存储：把库存从Hash改成String结构，避免了类型转换异常，降低了业务复杂度；
代码分层：抽离tryAcquireLock和releaseLock方法，复用性更好。

2.3 仍存在的问题

无锁续期：核心问题没解决！如果业务执行时间（比如扣减库存需要40秒）超过了LOCK_TIMEOUT（30秒），锁会提前过期，导致并发安全问题；
重试逻辑缺失：示例中加锁失败直接返回，实际场景需要增加“循环重试+最大重试次数”，避免瞬时并发导致加锁失败；
无异常处理：Integer.parseInt(stockStr)没有做异常捕获，如果库存值不是数字，会抛出运行时异常；
单点风险：依赖单个Redis节点，如果节点宕机，锁数据就丢了，可能导致多个客户端同时加锁。

方式3：生产级实现（Redisson客户端）

Redisson是Redis官方推荐的Ja va客户端，它内置了分布式锁的完整实现，解决了手动实现时遇到的诸多痛点。

2.1 代码逻辑拆解

@Resource
private RedissonClient redissonClient;
@Resource
private StringRedisTemplate stringRedisTemplate;

private void order() {
    // 1. 获取分布式锁对象（可重入锁）
    RLock lock = redissonClient.getLock("product:1001:lock");
    try {
        // 2. 加锁：最多等待10秒，锁30秒后自动释放；获取锁成功则执行业务
        if (lock.tryLock(10, 30, TimeUnit.SECONDS)) {
            try {
                // 3. 扣减库存业务逻辑
                Integer count = (Integer) stringRedisTemplate.opsForHash().get("product:1001",
"number");
                if (count != null && count > 0) {
                    stringRedisTemplate.opsForHash().put("product:1001", "number", count - 1);
                }
            } finally {
                // 4. 手动释放锁（若业务执行完未超时，主动释放）
                lock.unlock();
            }
        }
    } catch (InterruptedException e) {
        // 5. 中断异常处理，恢复线程中断状态
        Thread.currentThread().interrupt();
    }
}

2.2 核心优势（Redisson解决的痛点）

自动锁续期（看门狗机制）：
- 如果业务执行时间超过了锁超时时间，Redisson会启动后台线程（默认每10秒一次）自动把锁的超时时间续期到30秒；
- 只有当客户端正常释放锁或者宕机时，续期才会停止，这就彻底解决了“锁提前过期”的问题。
可重入性：基于Redis的Hash结构存储锁的持有次数，同一客户端多次tryLock不会导致死锁；
优雅的重试与等待：tryLock(waitTime, leaseTime, unit)支持“最大等待时间”，加锁失败时会阻塞等待，直到超时或者获取到锁；
原子性加锁/释放锁：底层封装了Lua脚本，保证加锁、释放锁的原子性；
集群适配：支持Redis主从、哨兵、集群模式，解决了单点风险（当然需要正确配置Redisson的集群模式）。

2.3 需注意的细节

解锁时机：必须在finally块中执行unlock()，但最好先判断lock.isHeldByCurrentThread()，避免未持有锁时执行解锁抛出异常；
异常处理：tryLock会抛出InterruptedException，需要捕获并恢复线程的中断状态，避免线程状态异常；
Redisson配置：生产环境要正确配置RedissonClient（比如连接池、超时时间、集群节点），否则可能导致锁性能下降甚至失效；
锁粒度：避免使用过大的锁粒度（比如“product:lock”），应该细化到具体资源（比如“product:1001:lock”），减少锁竞争。

三、三种实现方式对比与生产建议

实现方式	优点	缺点	适用场景
方式1（基础版）	代码简单、无额外依赖	释放锁非原子、无续期、易误删锁	测试环境、低并发非核心业务
方式2（Lua版）	释放锁原子化、代码结构清晰	无续期、重试逻辑需手动实现、单点风险	中小并发、核心逻辑简单场景
方式3（Redisson）	自动续期、可重入、集群适配	引入Redisson依赖、配置稍复杂	生产环境、高并发核心业务

生产环境核心建议

优先使用Redisson：手动实现分布式锁很容易遗漏边界条件（比如续期、原子性、集群支持），Redisson封装了成熟的解决方案，是生产环境的首选；
锁超时时间合理设置：结合业务平均执行时间来设置（比如业务平均执行5秒，设置超时30秒），避免过短导致续期频繁，过长导致死锁风险；
避免长时间持有锁：分布式锁应该“快进快出”，执行业务逻辑时尽量避开耗时操作（比如数据库慢查询、远程调用），必要时拆分锁粒度；
集群模式适配：如果Redis是集群/哨兵模式，Redisson需要配置RedissonNode或ClusterServersConfig，避免主从切换导致锁丢失；
兜底方案：分布式锁失效时，需要有兜底逻辑（比如数据库乐观锁），避免数据一致性问题。