Redisson分布式锁：从入门到"高并发恋爱大师"
引言：为什么需要分布式锁？
想象一下，你和你的情敌同时想给女神发微信表白，但女神手机只能接收一条消息------这时候就需要"分布式锁"来保证互斥性。在分布式系统中，多个服务实例可能争夺同一资源（比如库存、定时任务），而Redisson就是那个帮你优雅抢到"表白权"的"恋爱导师"。
一、Redisson简介：锁界的高富帅
Redisson是Redis官方推荐的Java客户端，不仅提供基础的Redis操作，还封装了分布式锁、延迟队列等高级功能。相比原生Redis的setnx命令，Redisson像一位"贴心管家"，自带看门狗自动续期 、可重入锁 、异步订阅重试等技能，彻底告别死锁和活锁的尴尬。
二、用法：三步搞定分布式锁
1. 引入依赖（Maven）
xml
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.17.7</version>
</dependency> 2. 配置Redisson客户端
java
@Configuration
public class RedissonConfig {
@Bean
public RedissonClient redissonClient() {
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:6379");
return Redisson.create(config);
}
} 3. 加锁与解锁
java
@Autowired
private RedissonClient redissonClient;
public void doSomething() {
RLock lock = redissonClient.getLock("myLock");
try {
// 尝试加锁，最多等待1秒，锁自动释放时间10秒
if (lock.tryLock(1, 10, TimeUnit.SECONDS)) {
// 你的核心业务代码
System.out.println("抢到锁了，开始干活！");
}
} finally {
lock.unlock(); // 务必在finally中释放锁
}
} 小贴士 ：tryLock不带参数可能导致解锁时报错，建议明确设置超时时间。
三、案例：秒杀系统中的"一人一单"
假设你负责一个秒杀系统，用户A同时用两个设备抢购同一商品，如何避免重复下单？
java
public Result seckill(Long voucherId) {
Long userId = getCurrentUser().getId();
RLock lock = redissonClient.getLock("lock:order:" + userId);
if (!lock.tryLock()) {
return Result.fail("禁止重复下单！");
}
try {
// 检查是否已下单
if (orderService.exists(userId, voucherId)) {
return Result.fail("每人限购一单！");
}
// 扣减库存并创建订单
seckillVoucherService.deductStock(voucherId);
orderService.createOrder(userId, voucherId);
} finally {
lock.unlock();
}
return Result.success();
} 效果：用户A在多设备同时请求时，只有一个请求能成功下单。
四、原理剖析：Redisson的"黑科技"
1. 加锁原子性：Lua脚本
Redisson通过Lua脚本在Redis中执行原子操作：
lua
if (redis.call('exists', KEYS[1]) == 0) then
redis.call('hset', KEYS[1], ARGV[2], 1);
redis.call('pexpire', KEYS[1], ARGV[1]);
return nil;
end; KEYS[1]是锁名（如myLock），ARGV[2]是客户端唯一标识（UUID + 线程ID）。
2. 可重入锁：Hash计数器
同一线程多次加锁时，Hash结构中的值会递增（解锁时递减），避免死锁：
redis
HINCRBY myLock 8743c9c0-0795-4907-87fd-6c719a6b4586:1 1 通俗解释：就像你家门锁，自己人进去一次计数器+1，出来一次-1，归零才真锁门。
3. 看门狗机制：自动续期
如果未指定leaseTime，Redisson会启动后台线程（看门狗），默认每10秒检查锁状态并续期至30秒，避免业务未完成锁已过期。
4. 解锁与容错
解锁时校验客户端标识，防止误删他人锁。若客户端宕机，锁超时自动释放，避免死锁。
五、对比：Redisson vs 原生Redis vs Zookeeper
| 特性 | Redisson | 原生Redis（setnx） | Zookeeper |
|---|---|---|---|
| 实现复杂度 | 低（封装完善） | 高（需手动处理） | 中（需处理监听） |
| 性能 | 高 | 高 | 较低（强一致性） |
| 死锁处理 | 自动续期 + 超时 | 依赖超时设置 | 会话失效自动释放 |
| 可重入 | 支持 | 不支持 | 支持 |
| 适用场景 | 高并发、低延迟 | 简单场景 | 强一致性场景 |
结论：Redisson在性能和易用性上完胜，但Redis主从切换可能导致锁失效（需RedLock补救）。
六、避坑指南：那些年我们踩过的"锁坑"
- 忘记释放锁 ：务必在
finally中解锁，否则锁泄漏变"死锁"。 - 锁超时时间过短：业务未执行完锁已释放，推荐让看门狗自动续期。
- 错误释放他人锁：使用唯一标识（UUID+线程ID）避免"误伤友军"。
- 过度依赖分布式锁：能用本地锁解决的问题，别用分布式锁（比如单服务实例）。
七、最佳实践：成为锁的"时间管理大师"
- 分段锁 ：将库存拆分为10个段（如
stock_1到stock_10），并发提升10倍。 - 监控告警 ：通过Redis监控工具（如Redisson的
RBatch）跟踪锁状态。 - 合理设置超时 ：根据业务耗时调整
leaseTime，避免频繁续期。
八、面试考点：如何征服面试官？
- Redisson锁的实现原理？
- Lua脚本保证原子性，Hash结构实现可重入，看门狗自动续期。
- 看门狗机制如何工作？
- 默认每10秒续期一次，锁超时时间重置为30秒。
- Redisson锁的缺点？
- Redis主从切换可能导致锁失效，需结合RedLock算法。
- 如何实现高性能分布式锁？
- 分段锁、减少锁粒度、异步续期。
总结：锁住"高并发"，释放"安全感"
Redisson像一位全能保镖，帮你优雅解决分布式系统中的资源竞争问题。但记住：锁虽好，可不要贪杯哦！合理评估场景，避免过度设计，才能让系统既安全又高效。
最后一句：如果你看完还不会用Redisson，建议转发给情敌，让他去踩坑吧！😉