Redisson分布式锁：从入门到“高并发恋爱大师”

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，建议转发给情敌，让他去踩坑吧！😉