基于Redisson实现分布式锁并分析其原理_redisson 多线程异常-CSDN博客

本文链接：https://blog.csdn.net/admin123404/article/details/110312761

问题：没加锁，高并发场景下会出现超卖问题。比如当前有三个线程同时访问这段代码，同时判断当前库存大于0，都减一，然后保存，结果三个线程都减一然后保存，但是stock的值还是199

解决：给key设置超时时间，过了这个时间自动删除此处为10秒自动删除

问题：上面这两条设置key和超时时间的代码无法保证原子性，假如刚设置完key，服务挂了，怎么办？

解决：可以一条命令设置key和超时时间一步搞定

问题：当前代码设置key时间为10s，但是执行业务逻辑的时候业务逻辑执行了15秒，由于key存在时间是10s ，肯定已经不存在了，当前环境有是高并发环境，另外一个线程进来一看，key不存在了，那么它就设置了一个key，设置存活时间为10s, 等到第二个线程又执行5s的时候，第一个线程代码已经走完了，由于finally里面会删除key，因此第一个线程会把key再次删除，此时它删除的是第二个线程刚刚设置的key,此时第三个线程进来了，一看key不存在，就设置key,存活时间依旧是10s，此时第二个线程走完删除key，把第三个线程的key删除...如此循环往复，会发现这个key一直就是被其他线程认为是不存在的key，因此其他线程都能访问此段代码，导致超卖情况依然会发生。

原理：假设当前有两个线程：线程1 和线程2 ，这两个线程同时访问业务代码。假设线程1拿到锁了，那么它就会设置setnx命令，线程2 判断自己没拿到锁，它就会一直等待线程一释放锁然后进行加锁。线程一拿到锁后会在后台启动一个线程用于判断当前key是否存在，若存在则把key的存活时间额外加上当前key设置的存活时间的1/3 。也就是说如果当前key的存货时间是9s，则在9s的基础上再加上3s 变成 12s。

分布式锁主要是为了解决高并发场景下的数据一致性问题的。一般就是涉及到多线程资源争抢时通过加锁来保证数据的安全性

场景：

模拟测试：

首先模拟一个抢购场景：

redis依赖：

代码：

在redis数据库存了一个stock值，相当于是库存，value是200

逻辑：首先去从redis里面取库存，判断当前库存是否大于0，如果大于0则库存减一

问题：没加锁，高并发场景下会出现超卖问题。比如当前有三个线程同时访问这段代码，同时判断当前库存大于0，都减一，然后保存，结果三个线程都减一然后保存，但是stock的值还是199

解决：

乍一看是没问题了，但是想一下，我们的服务有可能要部署多台，那么synchronized就没用了。因为synchronized是仅限于当前服务所在的jvm虚拟机，也就是单机环境下才有效。另外一个相同的服务启动的时候在另一个jvm里面，synchronized是锁不住的。

比如下面的场景：

一个服务我部署了两台，前端通过nginx转发到不同的服务去

nginx:

当我访问根目录，它会转发到redislock 下的两个服务中去。好，现在启动两个服务

下面进行高并发测试：

工具：Jmeter

首先配置一个线程组：

然后在线程组下面配置你要并发压测的接口

然后配置接口：

配置请求次数及时间

在执行前还可以打开压测报告：

开始

选择压测计划保存位置，此处我选择保存到桌面

执行完毕：

查看后台日志：

可以看到：两台服务在扣减库存后日志有显示库存相同的数字。这说明当前synchroinzed失效了。一样出现了两台机器扣除库存，库存同时减一的超卖情况。

来到正题了。像这种分布式环境下的问题应该怎么处理呢？

答案就是：使用分布式锁（使用redis、zookeeper）均可以实现

使用redis实现命令： setnx

这条命令和set命令的区别：

setnx 就是说如果当前setnx 的key 不存在，就会为key设置value值。否则不做任何操作。

set命令就是为key设置value，如果key不存在则为此key设置value，如果存在则会用新的value覆盖旧的value。

代码实现：

执行完后删除key

我讲一下执行逻辑：

假设当前有三个线程通过nginx进来转发到两个服务里面，假设线程一先执行到这段代码，那么它就会判断redis里面key="lockey"存不存在，一看，不存在那么它就会setnx，为key等于lockKey设置value "zhuge"

那执行完肯定返回true啊，接着就走下面的逻辑。其他两个线程一看，key为"lockKey" 已经存在了呀，那么就直接返回false了，就不会执行下面的扣减库存的代码了。

问题：

那么第一个线程拿到锁了，当它要执行下面的代码的时候突然因为你的业务代码抛异常了，那么会出现什么后果？

肯定是这个key就删除不了了嘛，它删除不了那redis里面一直有这个key,其他线程又得不到这个锁，那岂不是一件商品都卖不出去了嘛

那怎么办呢？

有小伙伴会说：搞一个try catch块，把代码放进去，delete key 放到finally里面去不就完了嘛

这样是可以解决代码异常的问题，但是不是从个本上解决的。还有问题。试想一下，你有个线程加锁进来了，正在执行代码的时候宕机了，或者是运维执行了 kill -9暴力终止程序进程，那怎么办？那你这个key不还是执行不到嘛，数据库里面还是会有这个key。

解决：给key设置超时时间，过了这个时间自动删除此处为10秒自动删除

问题：上面这两条设置key和超时时间的代码无法保证原子性，假如刚设置完key，服务挂了，怎么办？

解决：可以一条命令设置key和超时时间一步搞定

看下代码：

还有没有问题呢？答案是有的。

问题：当前代码设置key时间为10s，但是执行业务逻辑的时候业务逻辑执行了15秒，由于key存在时间是10s ，肯定已经不存在了，当前环境有是高并发环境，另外一个线程进来一看，key不存在了，那么它就设置了一个key，设置存活时间为10s, 等到第二个线程又执行5s的时候，第一个线程代码已经走完了，由于finally里面会删除key，因此第一个线程会把key再次删除，此时它删除的是第二个线程刚刚设置的key,此时第三个线程进来了，一看key不存在，就设置key,存活时间依旧是10s，此时第二个线程走完删除key，把第三个线程的key删除...如此循环往复，会发现这个key一直就是被其他线程认为是不存在的key，因此其他线程都能访问此段代码，导致超卖情况依然会发生。

怎么办？

解决：

我们可以在线程进来的时候为key设置一个唯一的value，然后执行finanny的时候去判断当前value和线程进来的时候设置的value是否一致。若一致则判断当前线程是设置此value的线程，则可以删除key，否则就认定当前线程不是设置key的线程。

那么现在还剩下一个问题：

就是我设置的这个key过期时间如果小于业务代码执行的时间，依然会导致key被删除从而引起其它线程进来，依然会导致超卖问题的发生。那该怎么处理这个问题呢？

有同学会说：给它设置时间长一点不就完了嘛。那服务宕机了怎么办呢？如果我服务宕机了又重启了，你给key设置60s，那我最起码得等一分钟才能重新设置这个key

解决：其实可以设置一个后台定时任务每隔一段时间判断这个key是否存在。若存在则给它的时间延长一段时间。

最终解决：使用redisson框架。

引入依赖：

配置代码：

使用：

引入依赖

业务代码：三行代码搞定

附上一段简单的代码：

public class TestController {
    @Autowired
    private static Redisson redisson;

    public static void main(String[] args) {
        String lockKey = "product_01";
        // 获取锁对象
        RLock lock = redisson.getLock(lockKey);
        // 加锁
        lock.lock();
        // 释放锁
        lock.unlock();
    }
}