目录
一 基于Redis的分布式锁优化
二 Redisson
Redisson是一个在Redis的基础上实现的Java驻Java内存数据网格。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。
1 实现步骤
1 导入依赖
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.13.6</version>
</dependency>2 配置Redisson客户端
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);
}
}
3 使用Redisson的分布式锁
2 Redisson可重入锁机制
解决的问题：
- 当你在一个方法内多次获取同一把锁（比如说递归调用），如果锁不可重入，会出现死锁，线程将自己锁死。
实现原理：
- 可重入锁作用对象指的是同一线程，使用的是Redis当中的Hash数据结构，存储一个计数器，当一个锁进入开始执行的时候，就将计数器加1，如果该锁执行结束就将计数器减1（为0时删除），这样避免了可重入锁之间锁的误删问题。
使用的技术
- 使用Hash的结构：Key是锁名称，Field是线程唯一标识，Value是重入次数。
- 通过使用Lua脚本保证操作的原子性。
3 Redisson可重试机制
要解决的问题：
当多个线程竞争同一把锁时，失败线程如果直接放弃，可能会导致业务无法正常执行，与设计的业务逻辑出现差错，但是如果无脑循环重试，又会浪费CPU的资源，增加Redis的压力。
解决方案：订阅发布机制+信号量控制+指数退避策略
1 订阅发布机制
订阅锁释放事件：
线程获取锁失败后，订阅 Redis 的特定频道（
redisson_lock__channel:{锁名称}），进入等待状态。不占用 CPU：通过 Redis 的 Pub/Sub 模型 阻塞监听，而非主动轮询。
锁释放通知：
当持有锁的线程释放锁时，向该频道发送解锁消息。
所有订阅该频道的线程会被唤醒，立即重试获取锁。
重试次数控制：
默认无限重试（直到成功），可通过trylock(...) 指定最大等待时间。
2 信号量控制
使用Semaphore限制阻塞 -- 同时尝试获取锁的线程数量，避免Redis瞬时压力过大。
3 指数退让策略
每次重试的等待时间按指数增长，减少无效次数
4 Redisson超时释放机制
解决的问题：
- 如果线程获取锁之后崩溃，没有释放锁，其他线程将永远无法获取锁，出现死锁现象。
核心逻辑：
1 锁续期触发条件：
- 当使用lock()不超过指定时间时，Redisson默认启用看门狗机制。
- 若手动指定超时时间lock(10,...)则不会启用看门狗，锁到期自动释放。
2 守护线程工作流程：
- 初始化：加锁成功后，启动一个后台守护线程。（非业务线程）
- 定期检查：每十秒检查一次业务线程是否仍然在执行（通过线程存活状态来判断）
- 锁续期：若业务未完成，通过Lua脚本重置锁的超时时间为30秒（维持锁的持有状态）
看门狗机制本质上就是一个续期机制，如果不调用 unlock()，看门狗会无限续期锁，直到持有线程异常终止或者执行unlock（），与业务是否完成无关。锁的续期不依赖业务是否执行完毕，而是依赖显式的 unlock() 调用。
后果：线程内不管有没有有业务执行只要没有unlock()释放，就会持续续期，将会在当前线程出现假死锁情况
5 RedissonMultiLock解决主从一致性
解决的问题：
- 在 Redis 的主从架构中，若主节点加锁后未及时同步到从节点即崩溃（触发哨兵机制），新主节点因无锁记录导致锁状态丢失，其他客户端可重复获取同一把锁，引发数据冲突。
解决方案：
并行加锁：向所有独立主节点发送加锁请求（相同锁名称 + 唯一线程标识）。
解决方案：
Redisson的运作流程
1 当客户端线程调用tryLock()传参方法申请加锁时（支持传入waitTime等待时长、leaseTime自动释放时间及TimeUnit时间单位）我们就会去获取锁，返回值为Boolean值，通过Redis的EXISTS命令检测锁Key，若不存在则表示当前线程为首个锁持有者，采用Redis Hash结构存储锁元数据，通过key-field-value三元组实现可重入计数。若锁Key已存在，通过对比Hash字段中的客户端UUID+线程ID验证线程身份，若是当前线程则执行重入操作，将重入计数器值递增，并刷新锁过期时间为默认30秒（可通过leaseTime配置）；若非当前线程，那就会通过PTTL命令获取锁剩余存活时间，与用户设定的waitTime进行超时判定，若未超期，订阅锁释放的Redis频道（可重试性），结合subscribe/publish实现线程阻塞控制，实现线程的等待，当执行的线程释放之后再去唤醒等待线程；若超过waitTime直接返回获取锁失败。
：传参的leaseTime自动施放时间只会在两种情况刷新一种是初始化，一种是线程重入。
：传参情况不会有看门狗自动续期的操作
2 当客户端线程调用tryLock()不传参方法申请加锁时：前面的校验相同，其核心区别不具有可重试性（没有waitTime）与超时自动释放机制（使用的是看门狗机制）。
：不具备可重试性的体现，在不是当前线程时就会直接返回false，而具备的会触发订阅加锁机制与线程阻塞机制。
：看门狗机制本质上就是一个续期机制，在不传入自动释放时间参数且不调用 unlock()，看门狗会无限续期锁，直到持有线程异常终止或者执行unlock()，与业务是否完成无关。锁的续期不依赖业务是否执行完毕，而是依赖显式的 unlock() 调用。
：可重入的对象是同一线程，重试性的条件是waitTime这个参数
三 trylock与lock两者有何区别
在Redisson中lock与trylock是两种不同的分布式锁实现方式，他们的核心区别在于阻塞行为，失败策略，参数配置。
首先lock是没有返回值的，如果没有加参数，就会持续阻塞等待，直到获取锁，同时必须手动unlock释放。其次trylock是由返回值的，其返回值是一个boolean的返回值，会尝试获取锁，如果没加参数获取失败就会返回false，加了参数会在waitTime等待时间范围之内进行等待，同时会在leaseTime自动释放不会使用看门狗机制。
| 特性 | 无参 lock() |
带参 lock(leaseTime) |
无参 tryLock() |
带参 tryLock(waitTime, leaseTime) |
|---|---|---|---|---|
| 阻塞行为 | 无限阻塞 | 无限阻塞 | 立即返回 | 在 waitTime 内阻塞 |
| 锁持有时间 | 看门狗续期（默认30秒） | 固定 leaseTime（禁用看门狗） |
看门狗续期 | 固定 leaseTime（禁用看门狗） |
| 可重试性 | 无限重试 | 无限重试 | 无重试 | 在 waitTime 内重试 |
| 是否自动释放 | 否（需手动解锁） | 是（按 leaseTime 释放） |
否（需手动解锁） | 是（按 leaseTime 释放） |
| 适用场景 | 强一致性长任务 | 短时任务，需自动释放 | 快速失败 | 平衡等待时间和可靠性 |
四 Redis优化秒杀
大体思路：判断库存与判断用户是否下过单在Redis的Lua脚本当中进行判断，再异步开启一个线程，来操作Mysql数据库。
需求：
- 1. 新增秒杀优惠券的同时，将优惠券信息保存到Redis中
@Override
@Transactional
public void addSeckillVoucher(Voucher voucher) {
// 保存优惠券
save(voucher);
// 保存秒杀信息
SeckillVoucher seckillVoucher = new SeckillVoucher();
seckillVoucher.setVoucherId(voucher.getId());
seckillVoucher.setStock(voucher.getStock());
seckillVoucher.setBeginTime(voucher.getBeginTime());
seckillVoucher.setEndTime(voucher.getEndTime());
seckillVoucherService.save(seckillVoucher);
//保存秒杀库存到Redis中
stringRedisTemplate.opsForValue()
.set(RedisConstants.SECKILL_STOCK_KEY + voucher.getId(), voucher.getStock().toString());
}- 2. 基于Lua脚本，判断秒杀库存、一人一单，决定用户是否抢购成功
--1参数列表
--1.1优惠券id
local voucherId = ARGV[1]
--1.2用户id
local userId = ARGV[2]
--2数据key
--2.1库存key
local stockKey = 'seckill:stock:' .. voucherId
--2.2订单key
local orderKey = 'seckill:order:' .. userId
--3 脚本业务
--3.1判断库存是否充足 get stockKey
if (tonumber(redis.call('get', stockKey)) <= 0) then
--库存不足，返回1
return 1
end
--3.2判断用户是否重复下单 sismember orderKey userId
if (redis.call('sismember', orderKey, userId) == 1) then
--用户重复下单，返回2
return 2
end
--3.3扣减库存 incrby stockKey -1
redis.call('incrby', stockKey, -1)
--3.4下单保存用户 sadd orderKey userId
redis.call('sadd', orderKey, userId)
return 0- 3. 如果抢购成功，将优惠券id和用户id封装后存入阻塞队列
- 4. 开启线程任务，不断从阻塞队列中获取信息，实现异步下单功能