day07-优惠券秒杀03

功能03-优惠券秒杀03

4.功能03-优惠券秒杀

4.6Redisson的分布式锁

Redis分布式锁—Redisson+RLock可重入锁实现篇

4.6.1基于setnx实现的分布式锁问题

我们在4.5自己实现的分布式锁，主要使用的是redis的setnx命令，它仍存在如下问题：

4.6.2Redisson基本介绍

Redisson是一个在Redis基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还提供了许多分布式服务，其中就包括了各种分布式锁的实现。

一句话：Redisson是一个在Redis基础上实现的分布式工具的集合。

据Redisson官网的介绍，Redisson是一个Java Redis客户端，与Spring 提供给我们的 RedisTemplate 工具没有本质的区别，可以把它看做是一个功能更强大的客户端

官网地址： https://redisson.org

GitHub地址： https://github.com/redisson/redisson

中文文档：目录 · redisson/redisson Wiki (github.com)

4.6.3Redisson快速入门

代码实现

（1）修改pom.xml，添加依赖

<!--redisson-->
<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;

/**
 * @author 李
 * @version 1.0
 */
@Configuration
public class RedissonConfig {
    @Bean
    public RedissonClient redissonClient() {
        //配置
        Config config = new Config();
        //redis单节点模式，设置redis服务器的地址，端口，密码
        config.useSingleServer().setAddress("redis://127.0.0.1:6379").setPassword("123456");
        //创建RedissonClient对象
        return Redisson.create(config);
    }
}

配置了之后，就可以在任意地方去使用Redisson了：比如说去改造之前的业务，使用Redisson的分布式锁

（3）修改VoucherOrderServiceImpl.java，使用Redisson的分布式锁

注入RedissonClient对象：

使用RedissonClient提供的锁：

（4）使用jemeter测试

分别向端口为8081、8082的服务器发送200个请求（使用同一个用户的token）

数据库中只下了一单：

说明解决了集群下的一人一单问题。

4.6.4Redisson可重入锁原理（Reentrant Lock）

可重入锁：字面意思是“可以重新进入的锁”，即允许同一个线程多次获取同一把锁。

比如一个递归函数里有加锁操作，递归过程中这个锁会阻塞自己吗？如果不会，那么这个锁就是可重入锁（因为这个原因可重入锁也叫做递归锁）。

Lock锁借助于底层一个voaltile的state变量来记录重入状态。如果当前没有线程持有这把锁，那么state=0，假如有线程持有这把锁，那么state=1，如果持有这把锁的线程再次持有这把锁，那么state就会+1 。

对于synchronized而言，它在c语言代码中会有一个count，原理和state类似，也是重入一次就加一，释放一次就减一 ，直到减少成零时，表示当前这把锁没有被人持有。

---

Redisson也支持可重入锁。Redisson在分布式锁中，采用redis的hash结构用来存储锁，其中key表示这把锁是否存在，用field表示当前这把锁被哪个线程持有，value记录重入的次数（锁计数）。当获取锁的线程释放锁前，先对锁计数-1，然后判断锁计数0，如果是0，就释放锁。

使用Redis的string类型的setnx命令，可以实现互斥性，ex可以设置过期时间。但如果使用hash结构，该结构中没有类似的组合命令，因此只能将之前的逻辑拆开。先判断是否存在，然后手动设置过期时间，逻辑如下：

可以看到，无论是获取锁还是释放锁，都比使用setnx实现的分布式锁复杂得多，而且实现需要有多个步骤。

因此，需要采用lua脚本来确保获取锁和释放锁的原子性：

• 获取锁的lua脚本

local key = KEYS[1]; -- 锁的key
local threadId = ARGV[1]; -- 线程唯一标识
local releaseTime = ARGV[2]; -- 锁的自动释放时间
-- 判断是否存在
-- 锁不存在
if(redis.call('exists', key) == 0) then
    -- 不存在, 获取锁
    redis.call('hset', key, threadId, '1');
    -- 设置有效期
    redis.call('expire', key, releaseTime);
    return 1; -- 返回结果
end;
-- 锁已经存在，判断threadId是否是自己
if(redis.call('hexists', key, threadId) == 1) then
    -- 如果是自己, 获取锁，重入次数+1
    redis.call('hincrby', key, threadId, '1'); -- hincrby命令是对哈希表指定的field对应的value增长指定步长
    -- 重新设置有效期
    redis.call('expire', key, releaseTime);
    return 1; -- 返回结果
end;
return 0; -- 代码走到这里,说明获取锁的不是自己，获取锁失败

• 释放锁的脚本

local key = KEYS[1]; -- 锁的key
local threadId = ARGV[1]; -- 线程唯一标识
local releaseTime = ARGV[2]; -- 锁的自动释放时间
-- 判断当前锁是否还是被自己持有
if (redis.call('HEXISTS', key, threadId) == 0) then
    return nil; -- 如果已经不是自己，则直接返回，不进行操作
end;
-- 是自己的锁，则重入次数-1
local count = redis.call('HINCRBY', key, threadId, -1);
-- 然后判断重入次数是否已经为0
if (count > 0) then
-- 大于0，说明不能释放锁，重置有效期然后返回
    redis.call('EXPIRE', key, releaseTime);
    return nil;
else  -- 等于0，说明可以释放锁，直接删除
    redis.call('DEL', key);
    return nil;
end;

代码测试

我们来测试一下Redisson的可重入锁：

package com.hmdp;

import lombok.extern.slf4j.Slf4j;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.springframework.boot.test.context.SpringBootTest;

import javax.annotation.Resource;
import java.util.concurrent.TimeUnit;

/**
 * @author 李
 * @version 1.0
 */
@Slf4j
@SpringBootTest
class RedissonTest {
    @Resource
    private RedissonClient redissonClient;

    private RLock lock;

    @BeforeEach
    void setUp() {
        lock = redissonClient.getLock("order");
    }

    @Test
    void method1() throws InterruptedException {
        // 尝试获取锁
        boolean isLock = lock.tryLock(1L, TimeUnit.SECONDS);
        if (!isLock) {
            log.error("获取锁失败 .... 1");
            return;
        }
        try {
            log.info("获取锁成功 .... 1");
            method2();
            log.info("开始执行业务 ... 1");
        } finally {
            log.warn("准备释放锁 .... 1");
            lock.unlock();
        }
    }

    void method2() {
        // 尝试获取锁
        boolean isLock = lock.tryLock();
        if (!isLock) {
            log.error("获取锁失败 .... 2");
            return;
        }
        try {
            log.info("获取锁成功 .... 2");
            log.info("开始执行业务 ... 2");
        } finally {
            log.warn("准备释放锁 .... 2");
            lock.unlock();
        }
    }
}

在method1()的boolean isLock = lock.tryLock(1L, TimeUnit.SECONDS);旁打上断点：

点击step over，显示获取锁成功：

打开redis，可以看到对应的hash数据，value记录的是线程重入锁的次数，此时value=1：

当前线程在method1()中调用method2()后，在method2()中重新获取锁，此时value记录的次数+1，value=2：

当method2()释放锁的时候，锁重入次数-1，value=1：

当执行到method1()释放锁的时候，锁重入次数-1，此时发现锁重入次数value=0，因此删除对应的key，真正释放锁。

我们进入RedissonLock的源码，发现里面也写了相关的lua脚本，这里的脚本和上面我们写的基本一致：

获取锁的脚本：

释放锁的脚本：

4.6.5Redisson的锁重试和WatchDog机制

（1）为什么需要WatchDog机制？

如果拿到分布式锁的节点宕机，且这个锁正好处于锁住的状态时，就会出现死锁问题。为了避免这种情况的发生，我们通常都会给锁设置一个过期时间。但随之而来又产生了新的问题：假如一个线程拿到了锁并设置了30s超时，但在30s后这个线程的业务没有执行完毕，锁已经超时释放了。可能会导致其他线程抢到锁，然后出现多线程并发的问题。

为了解决这种两难的境地：Redisson提供了watch dog 自动延期机制。

（2）WatchDog的自动延期机制

redisson中的看门狗机制总结

Redisson提供了一个监控锁的看门狗，它的作用是在Redisson实例被关闭前，不断的延长锁的有效期。也就是说，如果一个拿到锁的线程一直没有完成逻辑，那么看门狗会帮助线程不断的延长锁超时时间，锁不会因为超时而被释放。如果获取到分布式锁的节点宕机了，看门狗就无法延长锁的有效期，也避免了死锁的可能。

watchDog 只有在未指定加锁时间（leaseTime）时才会生效

默认情况下，看门狗的续期时间是30s，也可以通过修改Config.lockWatchdogTimeout来另行指定。另外Redisson 还提供了可以指定leaseTime参数的加锁方法来指定加锁的时间。超过这个时间后锁便自动解开了，不会延长锁的有效期。

---

（3）锁重试机制：利用信号量和PubSub功能实现等待、唤醒，获取锁失败的重试机制

（4）Redisson实例获取锁和释放锁的流程

（4.1）获取锁的逻辑：

• 首先去尝试获取锁，如果返回的ttl为null，则说明成功获取锁，然后需要判断是否走看门狗机制：
  • 如果我们自己设置了leaseTime，就不会开启watchDog机制，直接返回true；
  • 如果设置的leaseTime=-1，则开启watchDog，不停地更新有效期，然后返回true
• 如果返回的ttl不为null，说明获取锁失败。需要重试获取，在重试之前要先判断线程剩余的等待时间：
  • 如果剩余等待时间<=0，说明该线程没有机会获取锁了，直接返回false；
  • 如果如果剩余时间>0，就可以去尝试重新获取锁了。但是不是立即吃重试获取，需要去等待锁释放的信号：
    • 如果在等待中，等待时间大于了剩余等待时间，则直接返回false；
    • 如果收到了释放锁的信号，并且如果等待时间小于剩余等待时间，就重新开始尝试获取锁

重复上述所有步骤。最终线程要么成功获取锁，要么超时返回。

（4.2）释放锁的逻辑

尝试释放锁：

• 如果失败，记录异常，结束
• 如果成功，向等待的其他线程发送释放锁信息。然后取消watchDog机制，结束

4.6.6Redisson分布式锁总结

Redisson分布式锁原理：

• 可重入：利用hash结构记录线程id和重入次数
• 可重试：利用信号量和PubSub功能实现等待、唤醒，获取锁失败的重试机制
• 超时续约：利用watchDog，每隔一段时间（releaseTime/3），重置超时时间

4.6.7Redisson的联锁原理（multiLock）

上面我们已经介绍了Redisson分布式锁如何实现锁的可重入，锁获取时的重试，以及锁释放时间的自动续约。

现在来分析一下Redisson怎么解决主从一致性问题。要解决这个问题，主从一致性问题产生：

（1）主从一致性问题

为避免单节点的redis服务宕机，从而影响依赖于redis的业务的执行（如分布式锁），在实际开发中，我们往往会搭建Redis的主从模式。

什么叫做Redis的主从模式？

有多台Redis，将其中一台Redis服务器作为主节点，其他的作为从节点。一般主节点负责写入数据，从节点负责读取数据，当主节点服务器写入数据时会同步到从节点的服务器上。

一文读懂Redis的四种模式，单机、主从、哨兵、集群

但主从节点毕竟不是在同一台机器上，它们之间的数据同步会有一定的延时，主从一致性问题正是由于这样的延时而导致的：

假设有一个Java应用现在要来获取锁，它向主节点间发送了一个写命令：set lock thread1 nx ex 10，主节点上保存了这个锁的标识，然后主节点向从节点同步数据，但就在这时主节点宕机了。也就是说同步未完成，但主节点已经宕机了。

redis中的哨兵监控着整个集群的状态，它发现主节点宕机之后，首先断开与客户端的连接，然后在Redis Slave中选择一个当做新的主节点。

但是由于之前的主从同步未完成——也就是说锁已经丢失了。所以，此时我们的Java应用再来访问这个新的主节点时就会发现，锁已经没有了（锁失效了）。那么此时再有其他线程来获取锁也能获取成功，因此就会出现线程的并发安全问题——这就是主从一致性问题导致的锁失效问题。

（2）MultiLock锁

既然主从关系是一致性问题发生的原因，那么就不要使用主从节点了。我们将所有的节点都变为独立的redis节点，相互之间没有任何关系，都可以去做读写，每个节点的地位都是一样的。

此时我们获取锁的方式就改变了：获取锁时，要把加锁的逻辑写入到每一个独立的Redis节点上，只有所有的服务器都写入成功，此时才是加锁成功。

---

1. 假设现在某个节点挂了，那么去获得锁的时候，只要有一个节点拿不到，都不能算是加锁成功，保证了加锁的可靠性。

2. 因为没有主从节点，也就不会出现一致性问题；其次，随着redis节点的增多，redis可用性也提高了。

3. 为了提高可用性，我们也可以对所有独立的Redis Node分别建立主从关系，让它们去做主从同步。

   那么独立的Redis Node的主从关系会不会导致锁失效呢？

   我们假设此时有一个Redis Node宕机了，并且它的数据没有同步到它的从节点。这时如果有其他线程想去获取锁，因为在其他Redis Node上不能拿到锁，因此不算是获取锁成功。也就是说，只要有任意一个节点在存活着，那么其他线程就不能趁机拿到锁，解决了锁失效问题。

这样的方案保留了既主从同步机制，确保了Redis集群高可用的特性，同时也避免了主从一致引发的锁失效问题。这套方案在Redisson中被称为MultiLock锁（联锁）：redisson中的MultiLock，可以把一组锁当作一个锁来加锁和释放。

那么MutiLock 加锁原理是什么呢？笔者画了一幅图来说明

当我们去设置了多个锁时，redission会将多个锁添加到一个集合中，然后用while循环去不停去尝试拿锁，但是会有一个总共的加锁时间，这个时间是用需要加锁的个数 * 1500ms ，假设有3个锁，那么时间就是4500ms，假设在这4500ms内，所有的锁都加锁成功， 那么此时才算是加锁成功，如果在4500ms有线程加锁失败，则会再次去进行重试

4.7Redis优化秒杀

4.8Redis消息队列实现异步秒杀