深入浅出超详细从线程锁到 redis 实现分布式锁（篇节 1）

最新推荐文章于 2024-09-09 13:59:01 发布

花荣白起

最新推荐文章于 2024-09-09 13:59:01 发布

阅读量9.9w

点赞数 2

分类专栏： redis 文章标签：分布式 java redis nginx 多线程

本文链接：https://blog.csdn.net/qq_40304878/article/details/106299119

版权

redis 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

在使用 redis 实现分布式锁之前我们需要先了解以下几点

什么是分布式锁

要介绍什么是分布式锁，那首先要提到与之对应的的两个锁：线程锁和进程锁

1.线程锁

主要用来给方法、代码块加锁。当某个方法或者代码块使用锁时，那么在同一时刻至多仅有一个线程可以执行该段代码。当有多个线程访问同一对象的加锁方法/代码块时，同一时间只有一个线程在执行，其余线程必须要等待当前线程执行完之后才能执行该代码。但是，其余线程是可以访问对象中没有被加锁的代码。线程锁只在同一个JVM 中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如 Synchrogazeed、Lock 等。

2.进程锁

为了控制同一个操作系统中多个进程访问同一个共享资源，知识因为程序的独立性，各个进程是无法控制其他进程对资源的访问的，但是可以使用本地系统的信号量控制。

3.分布式锁

当多个进程不在同一个系统中时，使用分布式锁控制多个进程对资源的访问。

如何实现分布式锁？

实现分布式锁的方法有很多，比如：使用redis、ZK 等

本文就以 redis 为例，一步步来实现一把分布式锁。

redis 实现分布式锁

准备

建一个 springboot 项目，写一个前端控制器，控制器中就是简单模拟一个减库存的逻辑，库存放在 redis中。每次请求都减一次库存。

@Autowired
    private RedisTemplate<Object,Object> redisTemplate;

    @GetMapping("/cut")
    public Object kc(){
        redisTemplate.setKeySerializer(new StringRedisSerializer());
        int num = Integer.parseInt(redisTemplate.opsForValue().get("num").toString());
        if (num>0){
            int lastNum = num -1;
           redisTemplate.opsForValue().set("num",lastNum+"");
            System.out.println("扣减库存成功，剩余库存为："+lastNum);
        }else{
            System.out.println("扣减库存失败，库存不足");
        }
        return "ok";
    }

这里我们先不使用锁，看看请求过来，是否会产生问题

先来玩玩单应用线程锁吧

就先启动一个实例，接下来进行测试

测试1：手动浏览器低频率多次访问

在这里插入图片描述
貌似很和谐呀？库存也正常减少，每次访问，就减少一个，很不错。

是不是开始怀疑了，为什么要用锁呢？还搞什么线程锁进程锁分布式锁，这不用锁不也正常减库存，不也没问题？

你是不是这样想的的呢？

咱们继续往下走这才刚刚开始呢。。。

测试一返回结果

测试2：模拟高并发请求扣减库存接口

这里就使用 JMeter 来模拟高并发场景吧
设置库存 num = 1000
发送请求 1000 次
测试结果
剩余库存：518

按照我们的预想，每次请求就减少一个库存，库存总共 1000，发送了 1000 个请求，理论上库存应该为 0 啊，为什么剩余库存还有 518 呢？
再看上图，好多都是重复，一条记录代表一次请求，那么多次请求打印出来的剩余库存都是剩余 999，这就是问题

我们简单分析一下，看图
-请求1进来，获取到库存为：1000，然后往下执行，进行本地扣减库存，当1号本地扣减号库存后，准备将扣减完的剩余库存（999）保存到redis中时，此时还没来得及保存，2 号就进来了获取库存（1000）虽然1号本地减了库存，但是它没有保存同步到redis中，所以redis中的 num 值还是为 1000，此时 2 号进来获取到的库存就为 1000，依次类推，在 1 号 2 号还没有将剩余库存同步到redis 中时，3号 4 号 5号也进来了，获取库存值，还是为 1000，这时大家都拿着 num = 1000 往下执行，导致多次请求库存也只减少了1，我们就看到那么多打印相同剩余库存。
在这里插入图片描述 - 那之前测试1 为什么就没问题呢？

那是因为请求频率低，等下次一请求进来，我上一次请求就已经执行完减库存保存剩余库存的逻辑了，所以下一个进来就读到上一个扣减后的库存值，所以就没问题。

优化：加锁

使用 synchronized 实现线程锁

@GetMapping("/cut")
    public Object kc() {
        redisTemplate.setKeySerializer(new StringRedisSerializer());

        synchronized (this) {
            int num = Integer.parseInt(redisTemplate.opsForValue().get("num").toString());
            if (num > 0) {
                int lastNum = num - 1;
                redisTemplate.opsForValue().set("num", lastNum + "");
                System.out.println("扣减库存成功，剩余库存为：" + lastNum);
            } else {
                System.out.println("扣减库存失败，库存不足");
            }
        }
        return "ok";
    }

我们直接进行并发测试：库存：1000，请求次数：1000 老样子

开头
在这里插入图片描述
结尾
一千条打印，太长了，我就不全部贴出，就贴出一头一尾，从头尾就可以很明显看出与之前没有加锁的区别了吧。
每次请求减库存1，共请求了1000 次刚好剩余库存为：0
一次不信，认为巧合，可以多次试验一下，结果都是一样的（非分布式，仅此单体）

这下知道锁的作用了吧 hahahahah。。。。

要是单体架构，就一个项目部署一个 Tomcat 那是没啥问题（其他性能什么的锁优化什么的这里忽略哈）

那放在分布式架构多个 Tomcat 提供相同服务，那你这把锁还能锁住吗？
开干，带你来测试一下就知道了

那就来玩玩多应用线程锁吧，看看是否锁得住

还是上面的项目，但我们启动两个服务,同样进行库存扣减

对应端口为：
- 服务1：ip:8888
- 服务2：ip:9999

这里使用到了 NGINX 做负载均衡，NGINX 的使用，下期给大家讲哟。

我这里测试环境是 VM 虚拟机，centos7 ，在docker 中装了一个 Nginx 为了方便开发测试。

其实你用本地下载一个 NGINX ，然后开启动两次项目，提供两个服务，在NGINX上配置一下也是可以的。

在这里插入图片描述

OK 环境准备就绪，那就开始测试吧！

测试前我们先预想一下结果吧，1000 次请求，每次扣减 1，那么刚好请求解说库存就为：0。两个系统同时进行扣减，每人扣减一个刚好扣减完。应该理想就差不多这样子吧。

那现实呢？确实残酷的，看数据

服务1：
服务2：

两个服务出现了相同的数据，剩余库存都是：63，说明说明呢？

说明，库存 64 同时被两个服务获取到，这个就像前面我们讲的，多个线程同时读到相同的库存数1000 一样，上一个线程扣减库存还没保存，就被下一个库存进来读取错误的库存数，而分布式呢，就是服务1 读到库存为 64 然后进行执行本地扣减，在准备将扣减后的库存保存到 redis中时，原来这个另一个服务就进行读取库存操作，结果也读到 64，两个服务各自执行，结果出现两条相同的数据“ 扣减库存成功，剩余库存为：63”。

那有小伙伴就会问了，这不是加锁了吗？怎么还会出错？
在这里插入图片描述