前言

白嫖掘金很久了，最近学习了redis分布式锁的相关的知识，决定还是写一篇文章分享给大家，一是加强自己的记忆，二是希望能够给想了解相关知识的朋友一点思路。本文将使用nginx和2个集群的微服务来给大家展示为啥要用分布式锁，以及后面一步步的分析加锁的过程中会出现的问题。

简单的demo程序

这里有一个简单的demo程序，就是一个controller调用一次就操作一次redis减少一个库存

@RestController
public class GoodController {
    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @Value("${server.port}")
    private String serverPort;

    @GetMapping("/buyGoods")
    public String buyGoods() {
        String result = stringRedisTemplate.opsForValue().get("goods");
        int goodsNumber = result == null ?0 : Integer.parseInt(result);
        if(goodsNumber > 0) {
            int realNumber = goodsNumber - 1;
            stringRedisTemplate.opsForValue().set("goods", String.valueOf(realNumber));
            System.out.println("成功买到商品，库存还剩下" + realNumber + " 件" + "\t 服务提供窗口" + serverPort);
            return "成功买到商品，库存还剩下" + realNumber + " 件" + "\t 服务提供窗口" + serverPort;
        } else {
            System.out.println("商品已经售完/活动结束/调用超时，欢迎下次光临" + serverPort);
        }
        return "商品已经售完/活动结束/调用超时，欢迎下次光临" + serverPort;
    }
}

复制代码

其他配置类就不贴了，主要就是这么一个功能。 然后同样的代码，复制到另一个项目中。起两个微服务做集群。唯一区别就是一个端口是1111 另一个端口是2222

接着利用nginx转发和负载均衡 nginx的配置如下

upstream mynginx{
	server 127.0.0.1:1111 weight=1;
	server 127.0.0.1:2222 weight=1;}
    server {
        listen       80;
        server_name  localhost;

        #charset koi8-r;

        #access_log  logs/host.access.log  main;

        location / {
            proxy_pass http://mynginx;
            index  index.html index.htm;
        }
复制代码

做了一个轮询的负载均衡。

然后用JMeter创建一百个线程一秒钟 请求进来。

对比控制台打印的结果，很明显的看到出现了一个商品被多次售卖的情况

解决方案

考虑给redis上锁，现在生产上成熟的方案是直接用redisson。咱们先不用这个，就直接用redis的String setnx来上锁，然后分析有什么问题，以及redisson的出现到底解决了生产众的什么问题

首先是加锁，代码如下

结果如下

看了一下，没有出现一个商品被多次售卖的情况。 这里加锁的想法是这样的，定义一个常量就是锁的名称，当作是key，然后利用 setIfAbsent 这个方法的返回，key不存在就创建返回true，存在就返回false。然后自己用玩了，就删除这个key。

ok看起来一切正常，没有什么问题。但是，真的是这样吗？

1、当你获取锁之后，如果你接下来的业务处理报异常了，是不是不能成功的删除key，然后其他线程就一直都不能获取锁了，对吧。类似与 文件流、或者锁。你用的时候一定要保证释放。 所以咱们在删除key的地方加上finally

2、极端情况下，程序刚刚走到获取锁，然后程序突然宕机了，根本走不到finally，没办法保证解锁这时候怎么办？是不是可以考虑给这个key加上一个过期时间？ stringRedisTemplate.expire(REDIS_LOCK, 10L, TimeUnit.SECONDS); 加上这个代码，给redis设置一个过期时间，这样就能保证key能自动删除了

3、上面的代码变成了这样

这里还有一个问题是什么，建key和设置过期时间，这是两行代码，没有保证原子性，在高并发的情况下还是会出问题。所以图中的两行代码可以合并成一行 Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(REDIS_LOCK,value,10L, TimeUnit.SECONDS);这样就保证了创建key和设置过期时间的原子性

4、在这里，我们给这个key设置的过期时间是10秒。如果我们的业务处理时间超过了10秒，会出现什么情况？A线程自己的key已经被删除，B线程建了一个key。然后A处理完业务以后他自己的key已经超时。然后执行删除key的时候会发生什么？会删除B线程的key，然后B删除的时候会删除C的key，就这样全乱了。所以这里我们删除key这么写

比较这个value相等才能保证删除的是自己的key

5、到这一步了，还有问题吗？有的。上面finally里面的判断和删除锁，也不是原子的。怎么办，官方早就给了相关的解决方法。

没错，就是lua脚本。 直接上代码

6、到这里基本上就没啥问题了，还有一点需要解决的是：我们如何能够保证key的过期时间大于业务的执行时间。有人说：我设置一个很大的过期时间，可以吗？可以！这不就和上面说的第二条冲突了吗？所以最好的情况还是有效期能够有自动续期的功能。还有个问题是，目前我们都说的是单机的redis，生产中，你大概率会用到集群，主从哨兵模式。cap中redis属于是ap高可用，并不是强一致性的。情况再极端一点，key写入了主服务器，还没有完成同步，主服务器挂了，这时候选举出来的新主没有这个key的信息怎么办？集群环境下，自己写的这个锁还是不保险。

7、redisson闪亮登场了。 配置文件增加

这里是上的单机，也可以配置集群。

核心代码在这里

结语

这里通过首先自己写一个redis锁，一步步的分析问题以及最终的解决方案。至于redisson为什么能够解决上面的这些问题，还有key自动续期的问题。立一个flag，51之前看源码，弄清楚，然后再分享出来。最后还有一个问题，关于上面提到的第五点，获取和解锁原子性的问题，如果不让你用lua脚本，你有其他办法解决吗？

作者：TheChosenOne
链接：https://juejin.cn/post/6938671503282192414
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。