分布式锁是解决分布式系统中多节点并发访问共享资源的核心方案，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官方推荐的Java客户端，内置了分布式锁的完整实现，解决了手动实现的诸多痛点。
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”），减少锁竞争。
三、三种实现方式对比与生产建议
生产环境核心建议
- 优先使用Redisson：手动实现分布式锁易遗漏边界条件（如续期、原子性、集群），Redisson封装了成熟的解决方案，是生产首选；锁超时时间合理设置：结合业务平均执行时间设置（如业务平均执行5秒，设置超时30秒），避免过短导致续期频繁，过长导致死锁风险；避免长时间持有锁：分布式锁应“快进快出”，执行业务逻辑时避免耗时操作（如数据库慢查询、远程调用），必要时拆分锁粒度；集群模式适配：若Redis为集群/哨兵模式，Redisson需配置
RedissonNode或ClusterServersConfig，避免主从切换导致锁丢失；兜底方案：分布式锁失效时，需有兜底逻辑（如数据库乐观锁），避免数据一致性问题。四、总结
Redis分布式锁的核心是原子加锁+安全释放+超时兜底：
- 基础实现（方式1）仅适用于测试，核心问题是释放锁非原子、无续期；Lua脚本优化版（方式2）解决了释放锁原子性问题，但仍需手动处理续期、重试等逻辑；Redisson（方式3）是生产级方案，通过看门狗机制、可重入性、集群适配，解决了手动实现的所有核心痛点。
生产环境中，除非有特殊定制需求，否则优先基于Redisson实现分布式锁，既保证可靠性，又降低开发和维护成本。
到此这篇关于Redis分布式锁实现的三种方式-基于setnx，lua脚本和Redisson的文章就介绍到这了,
