#Redis黑马点评#（五）Redisson原理详解

一基于Redis的分布式锁优化

二 Redisson

1 实现步骤

2 Redisson可重入锁机制

3 Redisson可重试机制

4 Redisson超时释放机制

5 RedissonMultiLock解决主从一致性

三 trylock与lock两者有何区别

四 Redis优化秒杀

一基于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