Redis-分布式锁-redission原理
目录
分布式锁-redission功能介绍
分布式锁-Redission快速入门
分布式锁-redission可重入锁原理
分布式锁-redission锁重试和WatchDog机制
分布式锁-redission锁的MutiLock原理
分布式锁-redission功能介绍
重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。
不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。
超时释放：我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患
主从一致性： 如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。
那么什么是Redission呢
Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包含了各种分布式锁的实现。Redission提供了分布式锁的多种多样的功能。
分布式锁-Redission快速入门
引入依赖：
<dependency><groupId>org.redisson</groupId><artifactId>redisson</artifactId><version>3.13.6</version>
</dependency>配置Redisson客户端：
@Configuration
public class RedissonConfig {@Beanpublic RedissonClient redissonClient(){// 配置Config config = new Config();config.useSingleServer().setAddress("redis://192.168.150.101:6379").setPassword("123321");// 创建RedissonClient对象return Redisson.create(config);}
}
使用Redission的分布式锁
@Resource
private RedissionClient redissonClient;@Test
void testRedisson() throws Exception{//获取锁(可重入)，指定锁的名称RLock lock = redissonClient.getLock("anyLock");//尝试获取锁，参数分别是：获取锁的最大等待时间(期间会重试)，锁自动释放时间，时间单位boolean isLock = lock.tryLock(1,10,TimeUnit.SECONDS);//判断获取锁成功if(isLock){try{System.out.println("执行业务"); }finally{//释放锁lock.unlock();}}}在 VoucherOrderServiceImpl
注入RedissonClient
@Resource
private RedissonClient redissonClient;@Override
public Result seckillVoucher(Long voucherId) {// 1.查询优惠券SeckillVoucher voucher = seckillVoucherService.getById(voucherId);// 2.判断秒杀是否开始if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {// 尚未开始return Result.fail("秒杀尚未开始！");}// 3.判断秒杀是否已经结束if (voucher.getEndTime().isBefore(LocalDateTime.now())) {// 尚未开始return Result.fail("秒杀已经结束！");}// 4.判断库存是否充足if (voucher.getStock() < 1) {// 库存不足return Result.fail("库存不足！");}Long userId = UserHolder.getUser().getId();//创建锁对象 这个代码不用了，因为我们现在要使用分布式锁//SimpleRedisLock lock = new SimpleRedisLock("order:" + userId, stringRedisTemplate);RLock lock = redissonClient.getLock("lock:order:" + userId);//获取锁对象boolean isLock = lock.tryLock();//加锁失败if (!isLock) {return Result.fail("不允许重复下单");}try {//获取代理对象(事务)IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();return proxy.createVoucherOrder(voucherId);} finally {//释放锁lock.unlock();}}测试，首先需要将数据库中的数据复原：
然后，利用接口测试工具性测试：
发送请求后，响应体会显示请求成功，返回抢购订单的id，查看数据库：
两张表的数据同步，可见我们的Redisson框架整合成功。
分布式锁-redission可重入锁原理
在Lock锁中，他是借助于底层的一个voaltile的一个state变量来记录重入的状态的，比如当前没有人持有这把锁，那么state=0，假如有人持有这把锁，那么state=1，如果持有这把锁的人再次持有这把锁，那么state就会+1 ，如果是对于synchronized而言，他在c语言代码中会有一个count，原理和state类似，也是重入一次就加一，释放一次就-1 ，直到减少成0 时，表示当前这把锁没有被人持有。 在redission中，我们的也支持支持可重入锁，在分布式锁中，他采用hash结构用来存储锁，其中大key表示表示这把锁是否存在，用小key表示当前这把锁被哪个线程持有，所以接下来我们一起分析一下当前的这个lua表达式
这个地方一共有3个参数
KEYS[1] ： 锁名称
ARGV[1]： 锁失效时间
ARGV[2]： id + ":" + threadId; 锁的小key
exists: 判断数据是否存在 name：是lock是否存在,如果==0，就表示当前这把锁不存在；
redis.call('hset', KEYS[1], ARGV[2], 1);此时他就开始往redis里边去写数据 ，写成一个hash结构；
Lock{
id + ":" + threadId : 1
}
如果当前这把锁存在，则第一个条件不满足，再判断
redis.call('hexists', KEYS[1], ARGV[2]) == 1
此时需要通过大key+小key判断当前这把锁是否是属于自己的，如果是自己的，则进行
redis.call('hincrby', KEYS[1], ARGV[2], 1)
将当前这个锁的value进行+1 ，redis.call('pexpire', KEYS[1], ARGV[1]); 然后再对其设置过期时间，如果以上两个条件都不满足，则表示当前这把锁抢锁失败，最后返回pttl，即为当前这把锁的失效时间如果小伙帮们看了前边的源码， 你会发现他会去判断当前这个方法的返回值是否为null，如果是null，则对应则前两个if对应的条件，退出抢锁逻辑，如果返回的不是null，即走了第三个分支，在源码处会进行while(true)的自旋抢锁。
"if (redis.call('exists', KEYS[1]) == 0) then " +"redis.call('hset', KEYS[1], ARGV[2], 1); " +"redis.call('pexpire', KEYS[1], ARGV[1]); " +"return nil; " +"end; " +"if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +"redis.call('hincrby', KEYS[1], ARGV[2], 1); " +"redis.call('pexpire', KEYS[1], ARGV[1]); " +"return nil; " +"end; " +"return redis.call('pttl', KEYS[1]);"
Redisson框架的可重入原理：
在Redisson框架的底层，我们使用的是hash数据结构来存储锁的名字，当前线程，还有重入次数；当首次获取锁时，Redisson会记录这三个属性，因为是首次，其中的可重入次数为1；当线程再次获取锁时，Redisson会去判断当前请求获取锁是线程是否为当前线程，如果不是，则直接返回失败；如果是，则会让可重入次数自增1；当需要释放锁的时候，也是这样的思想，如果锁是自己的，则让可重入次数自减1，再去判断自减后的重入次数是否为0，如果为0，表示这个线程的锁全部释放了，如果不为0，表示最外层的锁依旧没有释放，次数就重新设置锁的有效期，避免因为时间的问题导致锁提前释放，就是给剩下的业务留下充足的时间。这就是Redisson框架的可重入原理。
分布式锁-redission锁重试和WatchDog机制
分析：
Redisson 锁重试机制Redisson 在获取分布式锁时，如果锁已被其他线程占用，并不会立即返回失败，而是会进入一个重试逻辑。它会通过循环尝试再次获取锁，期间会根据配置的等待时间（waitTime）和重试间隔（retryInterval）进行多次尝试。这种重试机制可以有效避免因瞬时锁竞争导致的获取失败，提高锁获取的成功率。当等待时间耗尽仍未获取到锁时，才会返回获取失败的结果。
Redisson WatchDog 机制WatchDog 是 Redisson 提供的自动续期机制，用于防止在持有锁的线程执行任务期间锁因过期时间到了而被自动释放。当客户端获取锁成功后，如果没有指定锁的过期时间，Redisson 会默认启用 WatchDog 线程，每隔一定时间（默认 30 秒的 1/3，即 10 秒）自动延长锁的有效期。这样可以保证只要持有锁的线程还在运行，锁就不会被其他线程提前抢占，直到任务完成并显式释放锁。
总结：
分布式锁-redission锁的MutiLock原理
为了提高redis的可用性，我们会搭建集群或者主从，现在以主从为例：此时我们去写命令，写在主机上， 主机会将数据同步给从机，但是假设在主机还没有来得及把数据写入到从机去的时候，此时主机宕机，哨兵会发现主机宕机，并且选举一个slave变成master，而此时新的master中实际上并没有锁信息，此时锁信息就已经丢掉了。
为了解决这个问题，redission提出来了MutiLock锁，使用这把锁咱们就不使用主从了，每个节点的地位都是一样的， 这把锁加锁的逻辑需要写入到每一个主丛节点上，只有所有的服务器都写入成功，此时才是加锁成功，假设现在某个节点挂了，那么他去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，就保证了加锁的可靠性。
原理：
当我们去设置了多个锁时，redission会将多个锁添加到一个集合中，然后用while循环去不停去尝试拿锁，但是会有一个总共的加锁时间，这个时间是用需要加锁的个数 * 1500ms ，假设有3个锁，那么时间就是4500ms，假设在这4500ms内，所有的锁都加锁成功， 那么此时才算是加锁成功，如果在4500ms有线程加锁失败，则会再次去进行重试.