Redisson
我们发现昨天的项目还是有些问题 昨天我们用lua脚本保证原子性 但是还是有几点问题
这个我们手动实现极其麻烦 所以我们选择一种成熟的技术 redisson Redisson是一个在Redis的基础上实现的Java驻Java内存数据网格。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。
实现步骤
导入依赖
xml
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.13.6</version>
</dependency>
java
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 {
@Bean
public RedissonClient redissonClient() {
Config config = new Config();
config.useSingleServer().setAddress("redis://192.168.100.100:6379").setPassword("tan2179432748");
return Redisson.create(config);
}
}
java
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脚本保证操作的原子性。
lua
--加锁
if not exists(KEY) then
hset KEY threadId 1
pexpire KEY leaseTime
return nil -- 成功
end
if hexists KEY threadId then
hincrby KEY threadId 1
pexpire KEY leaseTime
return nil -- 重入成功
end
return pttl(KEY) -- 锁被别人占用，返回剩余时间
--解锁
if not hexists(KEY, threadId) then
return nil
end
local counter = hincrby(KEY, threadId, -1)
if counter > 0 then
return 0 -- 还有重入没释放
else
del KEY
publish 解锁通知
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，判断是否超时。 - 没超时就进入重试机制：
- 更新时间
之后我们订阅通知
java
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逻辑：
lua
if not exists(KEY) then
hset KEY threadId 1; pexpire KEY internalLeaseTime; return nil
end;
if hexists KEY threadId then
hincrby 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 脚本实现严格的顺序控制，适用于需要公平性的场景。
选择建议：
优先使用非公平锁：在大多数高并发场景中，非公平锁性能更高。
使用公平锁：当业务逻辑对锁的获取顺序敏感时（如任务队列、资源分配）。