Redisson简明教程—你家的锁芯该换了
1.简介 2.看门狗 2-1.为什么需要这个"狗子"? 2-2.工作原理 2-3.如何“撸狗子” 3.可重入锁:你的分布式"万能钥匙" 3-1.Redisson可重入锁的魔法 3-2.使用姿势大全 3-3.公平锁 3-4.非公平锁 3-5.可重入原理深扒 4.联锁:分布式锁中的"全家桶套餐" 4-1.联锁是什么?——"要么全有,要么全无"的霸道总裁 4-2.为什么需要联锁? 4-3.联锁使用三件套 4-4.联锁的硬核原理 4-5.联锁的三大禁忌 5.Redisson读写锁:分布式系统中的"读写分离"高手 5-1.使用姿势 5-2.原理深扒 6.信号量(Semaphore):分布式系统中的"限量入场券" 6-1.使用姿势大全 6-2.原理深扒 7.红锁(RedLock):分布式锁界的“联合国维和部队” 7-1.核心原理 7-2.注意事项 7-3.使用姿势 8.闭锁(CountDownLatch):分布式系统中的"集结号" 8-1.使用姿势 8-2.原理深扒 9.总结
1.简介
各位攻城狮们,你还在使用原生命令来上锁么?看来你还是不够懒,饺子都给你包好了,你非要吃大饼配炒韭菜,快点改善一下“伙食”吧,写代码也要来点幸福感。今天咱们就来聊聊Redisson提供的各种锁,Redisson就像是Redis给Java程序员的一把瑞士军刀,不仅能存数据,还能玩出各种分布式花样。
Redis版本:Redis 2.8+,理想版本5.0+(支持 Stream、模块化等高级特性,Redisson 能秀出全部技能)。 架构模式:支持单机、哨兵和集群(集群模式可靠性更高)
2.看门狗
想象你上厕所(获取锁)时带着一只忠心耿耿的阿黄(看门狗)。当你蹲坑时间快到时(锁快要过期),阿黄就会大叫:"主人你还没完事吗?我给你续时间啦!"(自动续期)
2-1.为什么需要这个"狗子"?
防止业务没执行完锁就过期:默认锁30秒过期,但万一你的业务要31秒呢? 避免锁丢失:如果客户端崩溃,看门狗停止续期,锁最终会自动释放 不用手动计算业务时间:再也不用战战兢兢估算业务执行时间了
2-2.工作原理
首次加锁:默认设置锁过期时间30秒 启动看门狗:加锁成功后启动一个定时任务(后台线程) 定期续期:每10秒(过期时间的1/3)检查业务是否完成。未完成:执行expire命令把锁再续30秒;已完成:停止续期。 最终释放:业务完成调用unlock或客户端断开连接时释放
2-3.如何“撸狗子”
Config config = new Config();config.setLockWatchdogTimeout(30000L); // 单位毫秒,默认就是30秒// ...RedissonClient redisson = Redisson.create(config);// 你也可以在加锁时指定(会覆盖默认值)lock.lock(60, TimeUnit.SECONDS); 3.可重入锁:你的分布式"万能钥匙"
我们都知道Java中ReentrantLock和synchronized都是可重入锁,但都只能用于单机环境的,在分布式环境下,Redisson给我提供了类似体验的可重入锁。
3-1.Redisson可重入锁的魔法
线程安全:不同JVM的相同线程也可重入 自动续期:看门狗机制保活(默认30秒) 公平/非公平:两种模式可选 超时机制:避免无限等待
3-2.使用姿势大全
基础款(阻塞式):
RLock lock = redisson.getLock("orderLock");lock.lock(); // 一直等到天荒地老try {// 你的核心业务} finally { lock.unlock(); // 一定要放在finally!}高级款(尝试获取):
if (lock.tryLock(3, 30, TimeUnit.SECONDS)) { // 最多等3秒,锁30秒自动过期try {// 业务处理 } finally { lock.unlock(); }} else { log.warn("获取锁失败,换个姿势再试一次");}骚操作款(异步获取):
RFuture<Void> lockFuture = lock.lockAsync();lockFuture.whenComplete((res, ex) -> {if (ex == null) {try {// 异步业务处理 } finally { lock.unlock(); } }});3-3.公平锁
排队机制:使用Redis的List结构维护等待队列 订阅发布:通过Redis的pub/sub通知下一个等待者 双重检查:获取锁时检查自己是否在队列头部
RLock fairLock = redisson.getFairLock("myFairLock");try { fairLock.lock();// 业务逻辑} finally { fairLock.unlock();}3-4.非公平锁
直接竞争:所有线程同时尝试CAS操作 效率优先:没有队列维护开销 可能饥饿:运气差的线程可能长期得不到锁
RLock nonFairLock = redisson.getLock("hotItemLock");if (nonFairLock.tryLock(50, TimeUnit.MILLISECONDS)) { // 拼手速!try {// 秒杀业务逻辑 } finally { nonFairLock.unlock(); }}3-5.可重入原理深扒
加锁Lua脚本伪代码:
-- 参数:锁key、锁超时时间、客户端ID+线程IDif (redis.call('exists', KEYS[1]) == 0) then-- 锁不存在,直接获取 redis.call('hset', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]);returnnil;end;if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then-- 重入情况:计数器+1 redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]);returnnil;end;-- 锁被其他线程持有return redis.call('pttl', KEYS[1]); -- 返回剩余过期时间解锁Lua脚本伪代码:
-- 参数:锁key、客户端ID+线程IDif (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then-- 压根没持有锁returnnil;end;-- 重入次数-1local counter = redis.call('hincrby', KEYS[1], ARGV[1], -1);if (counter > 0) then-- 还有重入次数,更新过期时间 redis.call('pexpire', KEYS[1], 30000);return0;else-- 最后一次解锁,删除key redis.call('del', KEYS[1]);-- 发布解锁消息 redis.call('publish', KEYS[2], ARGV[2]);return1;end;4.联锁:分布式锁中的"全家桶套餐"
4-1.联锁是什么?——"要么全有,要么全无"的霸道总裁
想象你要同时约三个女神约会:
女神A:周末有空 ✅ 女神B:周末有空 ✅ 女神C:周末要加班 ❌ Redisson联锁的做法是:只要有一个拒绝,就取消所有约会!这就是联锁的"All or Nothing"哲学。
4-2.为什么需要联锁?
典型场景:
跨资源事务:需要同时锁定订单、库存、优惠券三个系统 数据一致性:确保多个关联资源同时被保护 避免死锁:防止交叉等待导致的死锁情况
4-3.联锁使用三件套
基本用法:
// 准备三把锁(就像三个女神的联系方式)RLock lock1 = redisson.getLock("order_lock");RLock lock2 = redisson.getLock("stock_lock");RLock lock3 = redisson.getLock("coupon_lock");// 创建联锁"约会套餐"RedissonMultiLock multiLock = new RedissonMultiLock(lock1, lock2, lock3);try {// 尝试同时锁定(约三位女神)if (multiLock.tryLock(3, 30, TimeUnit.SECONDS)) {// 三位都同意了!开始你的表演 processOrder(); updateStock(); useCoupon(); } else { log.warn("有个女神拒绝了你"); }} finally { multiLock.unlock(); // 记得送她们回家}高阶技巧:
// 动态构造联锁(适合不确定数量的资源)List<RLock> locks = resourceIds.stream() .map(id -> redisson.getLock("resource_" + id)) .collect(Collectors.toList());RedissonMultiLock dynamicLock = new RedissonMultiLock(locks.toArray(new RLock[0]));4-4.联锁的硬核原理
加锁流程:
顺序加锁:按传入锁的顺序依次尝试获取 失败回滚:任意一个锁获取失败时,释放已获得的所有锁 统一过期时间:所有锁使用相同的过期时间
底层Lua脚本(简化版):
-- 参数:多个锁的KEYS,统一过期时间,线程标识local failed = falsefor i, key inipairs(KEYS) doif redis.call('setnx', key, ARGV[2]) == 0then failed = truebreakend redis.call('expire', key, ARGV[1])endif failed then-- 释放已经获取的锁for j = 1, i-1do redis.call('del', KEYS[j])endreturn0endreturn14-5.联锁的三大禁忌
乱序使用(导致死锁):
// 线程1:multiLock(lockA, lockB).lock();// 线程2:multiLock(lockB, lockA).lock(); // 危险!可能死锁✅ 正确做法:全局统一加锁顺序
混合锁类型:
// 混合普通锁和公平锁new MultiLock(lock1, fairLock2); // 不推荐✅ 正确做法:使用相同特性的锁组合
忽略部分锁失败:
if (!multiLock.tryLock()) {// 直接返回,不处理部分获取成功的情况return; // 危险!}✅ 正确做法:确保完全获取或完全失败
5.Redisson读写锁:分布式系统中的"读写分离"高手
也许单机版的ReentrantReadWriteLock你听说过,但是分布式环境下的版本可能很少接触到。
典型场景:
读多写少系统:比如商品详情页(每秒上万次读取,每分钟几次更新) 数据一致性要求:保证读取时不会读到半成品数据 系统性能优化:避免读操作被不必要的串行化
5-1.使用姿势
RReadWriteLock rwLock = redisson.getReadWriteLock("libraryBook_123");// 读操作(多个线程可同时进入)rwLock.readLock().lock();try {// 查询数据(安全读取) Book book = getBookFromDB(123);} finally { rwLock.readLock().unlock();}// 写操作(独占访问)rwLock.writeLock().lock();try {// 修改数据(安全写入) updateBookInDB(123, newVersion);} finally { rwLock.writeLock().unlock();}5-2.原理深扒
加读锁Lua脚本(简化):
-- 检查是否可以加读锁(没有写锁或当前线程持有写锁)if redis.call('hget', KEYS[1], 'mode') == 'write' then -- 如果有写锁且不是当前线程持有,则失败if redis.call('hexists', KEYS[1], ARGV[2]) == 0 thenreturn0; end;end;-- 增加读锁计数redis.call('hincrby', KEYS[1], ARGV[1], 1);redis.call('pexpire', KEYS[1], ARGV[3]);return1;加写锁Lua脚本(简化):
-- 检查是否已有锁if redis.call('exists', KEYS[1]) == 1 then -- 如果是读模式或有其他写锁if redis.call('hget', KEYS[1], 'mode') == 'read' or redis.call('hlen', KEYS[1]) > 1 thenreturn0; end; -- 如果是当前线程持有的写锁(重入)if redis.call('hexists', KEYS[1], ARGV[2]) == 1 then redis.call('hincrby', KEYS[1], ARGV[2], 1);return1; end;end;-- 获取写锁redis.call('hset', KEYS[1], 'mode', 'write');redis.call('hset', KEYS[1], ARGV[2], 1);redis.call('pexpire', KEYS[1], ARGV[3]);return1;6.信号量(Semaphore):分布式系统中的"限量入场券"
同样的味道,Java中Semaphore的分布式版本。
6-1.使用姿势大全
基础用法:
// 获取信号量(初始10个许可)RSemaphore semaphore = redisson.getSemaphore("apiLimit");semaphore.trySetPermits(10); // 设置许可数量// 获取许可(阻塞直到可用)semaphore.acquire();try {// 执行业务(保证最多10个并发) callLimitedAPI();} finally { semaphore.release(); // 记得归还!}// 尝试获取(非阻塞)if (semaphore.tryAcquire()) {try {// 抢到许可了! } finally { semaphore.release(); }} else { log.warn("系统繁忙,请稍后再试");}高级技巧:
// 带超时的尝试获取if (semaphore.tryAcquire(3, 500, TimeUnit.MILLISECONDS)) {try {// 在500ms内获取到3个许可 batchProcess(); } finally { semaphore.release(3); // 归还多个许可 }}// 动态调整许可数量semaphore.addPermits(5); // 增加5个许可(扩容)semaphore.reducePermits(3); // 减少3个许可(缩容)6-2.原理深扒
获取许可的Lua脚本(简化):
-- 参数:信号量key、请求许可数local value = redis.call('get', KEYS[1])if value >= ARGV[1] thenreturn redis.call('decrby', KEYS[1], ARGV[1])elsereturn -1end释放许可的Lua脚本(简化):
-- 参数:信号量key、释放许可数return redis.call('incrby', KEYS[1], ARGV[1])7.红锁(RedLock):分布式锁界的“联合国维和部队”
RedLock 的诞生是为了对抗单点 Redis 挂掉后锁失效的问题。它的目标就是:“即使部分节点挂了,我也要稳如老狗”。
7-1.核心原理
Redisson 的 RedLock 实现来源于 Redis 作者 antirez 提出的 Redlock 算法。流程如下:
准备多个独立的 Redis 节点(注意:是互相独立的,不是主从复制结构)。 客户端依次向这些节点尝试加锁(使用 SET NX PX 命令)。 记录耗时:加锁操作总共不能超过锁过期时间的 1/2(比如设置锁有效期 10 秒,那就必须 5 秒内搞定加锁)。 加锁成功节点超过半数(N/2 + 1)视为成功。 若失败,立刻释放所有加锁成功的节点,以避免资源死锁。 释放锁时,同样要向所有节点发送 unlock 操作。
7-2.注意事项
RedLock 是为多主 Redis 实例准备的,不是给 Redis Cluster 用的。 你得维护多个彼此独立的 Redis 实例,部署和运维成本更高。 RedLock 的“强一致性”并非线性一致性,它只是通过多点确认提升“高可用性”。
7-3.使用姿势
// 准备多个独立的RLock实例RLock lock1 = redissonClient1.getLock("lock");RLock lock2 = redissonClient2.getLock("lock"); RLock lock3 = redissonClient3.getLock("lock");// 构造红锁(建议奇数个,通常3/5个)RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);try {// 尝试获取锁(等待时间100s,锁持有时间30s)boolean locked = redLock.tryLock(100, 30, TimeUnit.SECONDS);if (locked) {// 执行业务逻辑 doCriticalWork(); }} finally { redLock.unlock();}8.闭锁(CountDownLatch):分布式系统中的"集结号"
一样是Java的CountDownLatch的分布式版本,用法也是基本一样。
8-1.使用姿势
// 主协调节点(教官)RCountDownLatch latch = redisson.getCountDownLatch("batchTaskLatch");latch.trySetCount(5); // 需要等待5个任务// 工作节点(学员)RCountDownLatch workerLatch = redisson.getCountDownLatch("batchTaskLatch");workerLatch.countDown(); // 完成任务时调用// 主节点等待(在另一个线程/JVM)latch.await(); // 阻塞直到计数器归零System.out.println("所有任务已完成!");8-2.原理深扒
关键操作伪代码:
-- countDown操作local remaining = redis.call('decr', KEYS[1])if remaining <= 0then redis.call('publish', KEYS[2], '0') -- 通知所有等待者 redis.call('del', KEYS[1]) -- 清理计数器endreturn remaining-- await操作local count = redis.call('get', KEYS[1])if count == falseortonumber(count) <= 0thenreturn1-- 已经完成endreturn0-- 需要继续等待9.总结
Redisson 提供了丰富的分布式锁实现,适用于各种分布式场景,使用体验更好,选择锁类型时应根据具体业务场景和需求来决定,同时要注意锁的粒度和持有时间,避免分布式死锁和性能问题。
关于作者,高宏杰,转转门店技术部研发工程师。
想了解更多转转公司的业务实践,欢迎点击关注下方公众号: