Redisson分布式锁实战指南:原理、用法与项目案例
今天在项目练习中用到了Redisson分布式锁,这里介绍一下Redisson分布式锁的使用以及在项目中的使用案例。
一、为什么需要分布式锁?
在分布式系统中,多个服务实例可能同时操作共享资源(如库存扣减、订单处理)。传统的单机锁无法跨JVM工作,此时需分布式锁保证:
- 互斥性:同一时刻仅一个客户端持有锁
- 防死锁:持有锁的客户端崩溃时自动释放
- 可重入:同一线程可多次获取同一把锁
- 高性能:高并发下仍能快速响应
Redisson优势:基于Redis实现,支持可重入锁、锁续期、看门狗机制,API简洁且生产级可靠。
二、SpringBoot整合Redisson
1. 添加Maven依赖
<dependency><groupId>org.redisson</groupId><artifactId>redisson-spring-boot-starter</artifactId><version>3.23.2</version>
</dependency>
2. 配置Redis连接(application.yml)
spring:redis:host: 127.0.0.1port: 6379password: yourpassword
3. 注入RedissonClient
@Autowired
private RedissonClient redisson;
三、核心API及使用规范
RLock lock = redisson.getLock("orderLock"); // 锁名称需全局唯一// 推荐写法:设置锁超时时间(秒) + 自动续期 + 可重入
lock.lock(30, TimeUnit.SECONDS); try {// 业务代码(受保护的临界区)
} finally {lock.unlock(); // 必须放在finally块中确保释放
}
关键参数说明:
lock()
:阻塞式获取锁(默认30秒超时)tryLock(时间, 单位)
:非阻塞尝试获取锁- 锁续期:后台线程每10秒检查持有锁的客户端,自动续期至超时时间
四、项目案例:高并发库存扣减
场景描述
电商系统中,1000个用户同时抢购100件商品,需保证:
- 库存不超卖
- 扣减操作原子性
实现代码
@Service
public class InventoryService {@Autowiredprivate RedissonClient redisson;@Autowiredprivate RedisTemplate<String, Integer> redisTemplate;public boolean deductStock(String productId, int quantity) {String lockKey = "lock:product:" + productId;RLock lock = redisson.getLock(lockKey);try {// 尝试获取锁(等待5秒,锁持有30秒后自动失效)if (lock.tryLock(5, 30, TimeUnit.SECONDS)) {// 1. 检查当前库存Integer stock = redisTemplate.opsForValue().get("stock:" + productId);if (stock == null || stock < quantity) {return false; // 库存不足}// 2. 扣减库存(原子操作)redisTemplate.opsForValue().decrement("stock:" + productId, quantity);// 3. 记录订单日志(模拟DB操作)log.info("库存扣减成功:商品ID={}, 数量={}", productId, quantity);return true;}} catch (InterruptedException e) {Thread.currentThread().interrupt();log.error("获取锁中断异常", e);} finally {if (lock.isLocked() && lock.isHeldByCurrentThread()) {lock.unlock(); // 仅释放当前线程持有的锁}}return false;}
}
执行流程
- 线程A获取
lock:product:1001
锁 - 检查Redis库存 → 扣减 → 写日志
- 线程B尝试获取锁(最多等待5秒)
- 线程A执行完毕释放锁,线程B进入临界区
五、高级特性与避坑指南
1. 锁续期(看门狗)(Watchdog)
- 默认每10秒检查锁持有状态,若业务未完成则续期至30秒
- 注意:避免锁超时时间设置过短导致业务未完成锁已释放
2. 可重入锁验证
// 同一线程可多次获取锁(计数+1)
lock.lock();
lock.lock(); // 成功获取
lock.unlock(); // 计数-1
lock.unlock(); // 计数归零,实际释放
3. 避免死锁的实践
- 超时释放:显式设置锁超时(即使未手动解锁)
- 非阻塞尝试:用
tryLock()
替代lock()
避免线程永久阻塞 - 禁止嵌套异常:解锁代码禁止抛出异常(确保finally执行)
六、常见问题解答
Q:Redisson锁与Redis的SETNX有什么区别?
A:SETNX需自行实现续期、重入等机制,Redisson提供完整的分布式锁解决方案。
Q:锁超时时间如何设置?
A:应根据业务最长耗时设置(如平均耗时200ms,可设超时1s),建议添加熔断降级。
Q:主从切换时是否安全?
A:Redisson提供红锁(RedLock) 算法(需至少3个独立Redis主节点),但多数场景单节点已足够。
七、总结
Redisson通过简单的API解决了分布式锁的核心问题:
- 可重入锁 → 避免线程自我阻塞
- Watchdog机制 → 防止业务未完成锁提前释放
- 多种锁类型 → 支持公平锁、联锁(MultiLock)、红锁等
最佳实践:锁粒度要细(如按商品ID加锁)、超时时间合理、解锁逻辑必须可靠!