Redis分布式锁（不使用会出现哪些问题）

1。从最原始的代码中发现问题，一步步解决

1）环境搭建：首先创建两个springboot服务

2） pom文件

3）配置文件

4）配置类

5）业务代码

两个demo除了端口号不一样其它没区别

2.搭建完成，启动demo1，demo2，测试访问成功

 

 

 

 3.以上程序会有哪些问题呢，大家来找茬

     1）第一个问题：很容易发现程序没有加锁，单机版锁的问题，在多线程的环境下会有安全隐患

改进：加锁（2.0版本）

 这里的加锁也是有讲究的

是使用synchronized（特点：不见不散）还是使用ReentrantLock（特点：过时不候）ReentrantLock是可以使用tryLock()方法设置等待时间的，这里为了演示使用synchronized

这里的测试就不演示了

        2）第二个问题：分布式部署后，单击锁还是会出现超卖现象，需要分布式锁，为了演示分布式，可以使用nginx反向代理

nginx的配置：

 

 

 并且测试访问成功

 看似没有问题，使用jmeter测压发现两个demo重复购票，这时候单机锁就不起效果了

        改进：使用redis的setnx命令（3.0版）

 

         3）第三个问题：这样删除锁是有问题的，万一没有执行到stringRedisTemplate.delete(REDIS_LOCK)这行代码出现了异常，那么锁就解不了了

 改进：使用finally（4.0版）

          4）第四个问题：万一机器宕机了，或者机房着火了，finally这行代码根本执行不到，导致还是解锁失败

改进：给锁加一个过期时间（5.0版）

        5）以上代码就没有问题了吗？？？还有问题，第五个问题：加锁和设置过期时间不在同一行，即不是一个原子性操作

 改进：把他们写在同一行（6.0版）

        6）第六个问题：以上设置的过期时间是10秒钟，有时我们执行业务操作也许只需要5秒，那没有问题，哪个突然执行业务代码的时候需要15秒，那就出现了过早删锁了，导致其它线程也过来了

 改进：只删除自己的锁，不可以删别人的锁（7.0版）

        7）第七个问题：不难发现，以上两行操作不是原子性的，所以还是会有很严重的问题

改进：很多人肯定想到了lua脚本（可以参考地址SET | Redis）

 但是现在有限制，不可以使用lua脚本怎么办呢，你还有其它想法吗？（工作中还是推荐lua脚本）

改进：可以使用redis的事务（8.1版）

 

 

 改进：使用lua脚本（8.2版）

Jedis jedis = JedisUtils.getJedis();

String script=" if redis.call("get",KEYS[1]) == ARGV[1]
        then
            return redis.call("del",KEYS[1])
        else
            return 0
        end ";

Object o=jedis.eval(script,Collections.singletonList(REDIS_LOCK),Collections.singletonList(value));

if("1".equels(o.toString)){
    System.out.println("del lock success");
}else{
    System.out.println("del lock fail");
}

JedisUtils自己设置一下，捕获异常和关闭资源自己解决一下

        8）第八个问题：就是以上设置的缓存时间和业务时间之间不好确定，不要确定缓存时间的设置

改进：缓存续期（9.0版），使用redisson

 加入依赖

解决代码如下：

以上解锁方法还有优化一下

 

大家还可以去了解一下Redisson是如何缓存续期的（看门狗机制）

 结束结束！！！