当前位置：首页 > news >正文

Redisson

news 2025/7/17 6:24:34

Redisson

我们发现昨天的项目还是有些问题昨天我们用lua脚本保证原子性但是还是有几点问题

这个我们手动实现极其麻烦所以我们选择一种成熟的技术 redisson Redisson是一个在Redis的基础上实现的Java驻Java内存数据网格。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。

实现步骤

导入依赖

    <dependency><groupId>org.redisson</groupId><artifactId>redisson</artifactId><version>3.13.6</version></dependency>

package com.hmdp.config;import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;@Configuration
public class RedissonConfig {@Beanpublic RedissonClient redissonClient() {Config config = new Config();config.useSingleServer().setAddress("redis://192.168.100.100:6379").setPassword("tan2179432748");return Redisson.create(config);}
}

				Long userId = UserHolder.getUser().getId();
//        SimpleRedisLock lock = new SimpleRedisLock();RLock lock = redissonClient.getLock(SECKILL_VOUCHER_ORDER + voucherId);boolean isLock = lock.tryLock();if (!isLock) {// 索取锁失败，重试或者直接抛异常（这个业务是一人一单，所以直接返回失败信息）return Result.fail("一人只能下一单");}try {// 索取锁成功，创建代理对象，使用代理对象调用第三方事务方法， 防止事务失效IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.createVoucherOrder(userId, voucherId);} finally {lock.unlock();}

通过redissonClient中的getlock来拿到锁实现分布式锁从而解决上面我们提到的问题

那么redisson底层到底是怎么实现的呢

可重入锁机制

可重入锁作用对象指的是同一线程，使用的是Redis当中的Hash数据结构，存储一个计数器，当一个锁进入开始执行的时候，就将计数器加1，如果该锁执行结束就将计数器减1（为0时删除），这样避免了可重入锁之间锁的误删问题。

使用Hash的结构：Key是锁名称，Field是线程唯一标识，Value是重入次数。
通过使用Lua脚本保证操作的原子性。

--加锁
if not exists(KEY) thenhset KEY threadId 1pexpire KEY leaseTimereturn nil -- 成功
end
if hexists KEY threadId thenhincrby KEY threadId 1pexpire KEY leaseTimereturn nil -- 重入成功
end
return pttl(KEY) -- 锁被别人占用，返回剩余时间
--解锁
if not hexists(KEY, threadId) thenreturn nil
end
local counter = hincrby(KEY, threadId, -1)
if counter > 0 thenreturn 0 -- 还有重入没释放
elsedel KEYpublish 解锁通知return 1
end

从而避免误删

订阅发布 + 信号量+watchdog续期

首先进入trylock

我们目的是线程尝试获取锁，失败后不自旋浪费 CPU，而是等待通知，再间歇性重试。

从 public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) 开始：

记录最大等待时间 time = waitTime 毫秒 和起始时间 current = now。
调用 tryAcquire(...) 尝试一次获取锁：
- 成功返回 null → 获取锁结束。
- 失败返回剩余 TTL（锁还有多久过期）。
失败则进入等待：
- 更新时间 time -= now - current，判断是否超时。
- 没超时就进入重试机制：

之后我们订阅通知

RFuture<RedissonLockEntry> subFuture = subscribe(threadId);
if (!subFuture.await(time, MILLISECONDS)) {// 超时或失败 -> unsubscribe + return false
}
...
while (true) {ttl = tryAcquire(...);if (ttl == null) return true;// 失败，计算剩余time// 根据 ttl 和 time，使用信号量尝试阻塞等待： latch.tryAcquire(ttl, MILLISECONDS);
}

发布订阅机制：通过 subscribe 订阅 redisson_lock__channel:{lockName}，发布者在解锁时 PUBLISH 解锁通知，唤醒订阅者阿里云开发者社区+15CSDN博客+15CSDN博客+15阿里云开发者社区+1CSDN博客+1。
信号量控制：使用 Latch（基于信号量的阻塞队列）等待通知到达。在 TTL 时间内阻塞，而非空转轮询。
不会所有失败线程立马重试，避免 Redis 瞬时压力暴涨。

接下来 Lua 脚本尝试取锁（tryLockInnerAsync）

核心是这段 Lua逻辑：

if not exists(KEY) thenhset KEY threadId 1; pexpire KEY internalLeaseTime; return nil
end;
if hexists KEY threadId thenhincrby KEY threadId 1; pexpire KEY internalLeaseTime; return nil
end;
return pttl(KEY)

不存在锁→加锁 + 设置过期 → 返回 nil（代表成功）。
重入同一线程 → 自增计数 + 续期 → 返回 nil。
被其他线程占用 → 返回剩余 TTL（毫秒）

该 TTL 被上层用于判断等待时长和重试间隔。

最后用watchdog续约

当 leaseTime=-1（未指定显式 lease 时间），会启动 "看门狗"续租逻辑：

内置 TTL 为 config.lockWatchdogTimeout()，默认 30s，用于续期。
Lua 检查获取到锁，如果 ttlRemaining == null，即成功获取，则调度续期。续约任务周期为 TTL/3

看门狗机制本质上就是一个续期机制，如果不调用 unlock()，看门狗会无限续期锁，直到持有线程异常终止或者执行unlock（），与业务是否完成无关。锁的续期不依赖业务是否执行完毕，而是依赖显式的 unlock() 调用。

后果：线程内不管有没有有业务执行只要没有unlock()释放，就会持续续期，将会在当前线程出现假死锁情况

redisson解决主从一致性

当然在 Redis 的主从架构中，若主节点加锁后未及时同步到从节点即崩溃（触发哨兵机制），新主节点因无锁记录导致锁状态丢失，其他客户端可重复获取同一把锁，引发数据冲突（即使有AOF和RDB快照也无法修复因为从节点并未崩溃）

对于这个问题 redisson选择一视同仁不接受主节点和从节点的区别向所有独立主节点发送加锁请求（相同锁名称 + 唯一线程标识）（并行加锁）

公平锁先请求的锁先获取锁

Redisson 默认是非公平锁，但支持显式创建公平锁（RFairLock）。
公平锁通过 Redis 的 ZSet 和 Lua 脚本实现严格的顺序控制，适用于需要公平性的场景。
选择建议：
优先使用非公平锁：在大多数高并发场景中，非公平锁性能更高。
使用公平锁：当业务逻辑对锁的获取顺序敏感时（如任务队列、资源分配）。

查看全文

http://www.dtcms.com/a/282331.html