Redisson（一）：分布式下高并发的问题

Redis分布式锁

为什么要用到分布式锁呢？

对于单机项目来说，不需要使用到分布式锁，只要使用自己JVM的锁就够用了，但是当项目搭上了集群之后，同个项目是有几个实例去对外提供服务的，那么就需要使用分布式锁，本质来说分布式锁就是让不同实例之前可以使用同一把锁

实现

Redis作分布式锁，本质上就是使用了一条set命令

setnx key value

这个命令的作用是

• 假如key不存在，就如一般的set key value命令一样，只是往数据库添加键值对
• 假如key存在，原本的set key value是会对存在的key对应的value进行覆盖，而对于setnx命令来说，是不进行任何操作的！！！

其实setnx的对应的意思就是set if not exist，对应的redisTemplate方法是setIfAbsent，返回一个布尔值，代表是否设置成功

下面来简单实现一下

    public void lock(){
        //定义锁的名字，代表锁了什么资源，比如这是一把仓库锁
        String lockName = "stock-lock";
        //进行加锁
        while (true){
            //进行setnx 加锁
            if(redisTemplate.opsForValue().setIfAbsent(lockName,"myLock")){
                break;
            }
            //加锁失败，继续去加锁
        }
        //加锁成功才会出来
        try{
            //做业务逻辑
        }finally {
            //释放锁
            redisTemplate.delete(lockName);
        }
    }

整体的步骤也比较简单

• 尝试进行获取锁
  • 获取锁失败，回旋继续获取锁
  • 获取锁成功，执行业务逻辑，并且finally最终释放锁

这出现了一个问题，假如获取锁的项目实例挂了怎么办，即锁永远不会被释放出来，那就完蛋了。

所以，我们可以给锁设置一个过期时间，但要注意，必须是一个原子性操作，也就是获取锁和设置过期时间必须为一个原子，要么同时失败，要么同时成功，否则在获取锁成功，实例就挂了，造成的结果是一样的

所幸，Redis提供了这个原子性操作

//获取锁成功并给锁设置10S的过期时间
redisTemplate.opsForValue().setIfAbsent(lockName,"myLock",Duration.ofSeconds(10)

那这样就没问题了吗？

不，其实还有一个很严重的问题，就是锁续命！！！

高并发情境下出现的问题

从上面的代码上可以注意到，所有的实例都是共用一把锁，对于低并发量来说可能没什么问题，但对于真正业务上的高并发，就会产生致命的问题

回看我们的代码，经过设置成功后，变成了下面

    public void lock(){
        //定义锁的名字，代表锁了什么资源，比如这是一把仓库锁
        String lockName = "stock-lock";
        //进行加锁
        while (true){
            //进行setnx 加锁
            boolean flag = redisTemplate.opsForValue().
                    setIfAbsent(lockName,"myLock",Duration.ofSeconds(10));
            if(flag){
                break;
            }
            //加锁失败，继续去加锁
        }
        //加锁成功才会出来
        try{
            //做业务逻辑
        }finally {
            //释放锁
            redisTemplate.delete(lockName);
        }
    }

在这里，我们已经给锁设置了10S的过期时间，假如，一个线程成功获取了锁并且加上了过期时间，但这个线程没在锁规定的过期时间完成它的业务，即锁过期了，这个线程依然在执行业务，没有走到最后finally释放锁的流程，锁就已经过期了

只要一旦释放了锁，在高并发的场景下，就会立马有线程去获取锁，假如此时线程B获取了锁，那么此时前面一个线程A执行太慢了，锁过期了还没执行完，当B获取了锁之后，线程A执行完了，执行delete操作，把B的锁给释放掉了，让其他线程又可以去获取了，从而造成一系列连锁的反应

从这个场景来看，我们可以分析得出两个问题

1. 无法保证线程在锁的过期时间内完成业务，需要进行锁续命
2. 线程可能存在释放别人的锁的问题

第二个问题比较好解决，我们只需要让其他线程意识到这把锁不是自己的，就不会释放别人的锁了，我们可以让value来当作锁的标签，表明这把锁是谁的！！！

    public void lock(){
        //定义锁的名字，代表锁了什么资源，比如这是一把仓库锁
        String lockName = "stock-lock";
        //给锁贴上一个标签，表明这把锁是我的
        String myName = UUID.randomUUID().toString();
        //进行加锁
        while (true){
            //进行setnx 加锁
            boolean flag = redisTemplate.opsForValue().
                    setIfAbsent(lockName,myName,Duration.ofSeconds(10));
            if(flag){
                break;
            }
            //加锁失败，继续去加锁
        }
        //加锁成功才会出来
        try{
            //做业务逻辑
        }finally {
            //获取锁的标签，并判断是不是自己的锁
            //自己的锁就释放掉
            if(myName.equals(redisTemplate.opsForValue().get("stock-lock"))){
                //释放锁
                redisTemplate.delete(lockName);
            }
        }
    }

解决掉了第二个问题，但我们依然没有解决第一个问题，那就是如何保证线程在锁过期时间内完成业务

所以就有了锁续命的问题

锁续命

什么是锁续命呢？

在获取锁成功后，我们就开启一个子线程，子线程去监控线程是否已经完成了业务，如果没有完成业务，就给锁延长过期时间，知道线程完成了业务，就不再继续延长过期时间，让线程可以去释放锁，即使线程突然挂了，锁依然有着过期时长，不怕不会被释放掉