redis 性能测试（三）：Redission 分布式锁的并发测试

这是我参与11月更文挑战的第7天，活动详情查看：2021最后一次更文挑战

Redission 分布式锁的并发测试

前言

在单机场景下，可以使用内置锁来实现进程同步，但在分布式场景下需要同步的进程可能位于不同节点，就需要在分布式部署的应用集群中使用分布式锁，即同一个方法只能被一台机器上的一个线程来执行，分布式锁的用途就是解决分布式环境下同一个方法被客户端调用的一致性问题，同时 redis 本身也可能是集群的，

而在集群环境下 Redis自带的分布式锁会面临一个问题，它加锁只作用在一个 Redis 节点上，如果master 因为某些原因进行了主从切换，那么该锁可能就会丢失，因此 Redis 的作者提出了 RedLock 算法来解决这个问题，这里我不讲这个细节，只记住redisssion包它本身已经对 Redlock算法进行了封装，所以它是可以保证 Redis集群和服务节点分布式下的安全性问题。

Redission 在分布式中的应用是非常的广泛的，这篇文章将对 redission 进行分布式压力测试，结果好为后续开发做参考。

一、项目引入 Redission

        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson-spring-boot-starter</artifactId>
            <version>3.15.5</version>
        </dependency>

yml 配置

spring:
  application:
    name: springboot-redisson
  redis:
    redisson:
      singleServerConfig:
        password: 123456
        address: "redis://127.0.0.1:6379"

二、模拟并发请求压测

2.1 提前准备数据

提前在 redis 中将它 NUM 的值设为0。

路过的请求将 该NUM值加1。

2.2 不加锁测试

在这版本中，我们不用分布式锁，将该值加1代码如下

redisTemplate.opsForValue().increment("NUM",1);

使用 JMeter 来测试

1） 10线程并发请求

值是没有问题的，下面开始正式测试。

2）1000线程并发请求

1000次并发没有问题，

3）10000线程并发请求

在一秒1w次的并发压力下，出现了问题。

4）5000线程并发测试

此时异常率为 9.58%。

5）3000线程并发测试

正常

6）4000线程并发测试

正常

7）4500 线程并发测试

异常率为3.16%

在经过这次测试后，发现在不加锁的情况下，1s内并发请求达到 4000-4500内就会出现异常现象。

2.3 分布式测试

这里我们通过 Redission 的分布式锁来测试。

    @PostMapping("/environment/find")
    public ResponseData<List<EnviromentReportVO>> enviList(@RequestBody RequestData<ReportDTO, UserVO> requestData){
        RLock lock = redissonClient.getLock("lei");
        lock.lock();
        System.out.println(Thread.currentThread().getName()+"获得锁");
        try { 
            Thread.sleep(10);
            redisSdk.incrementInt("NUM",1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }finally {
            System.out.println(Thread.currentThread().getName()+"释放锁");
            lock.unlock();
        }
        return null;
    }

原理是在加锁期间，其他锁无法占用该锁，直到该锁到期后才可以占用。

1）5000 线程并发请求

在5000 次并发请求下，是没有问题的，但是使用分布式锁之后，吞吐率下降了几十倍，耗时1分21秒。redis 的值也变为了 5000

2）7000线程并发请求

7000 次并发请求正常，耗时近2分钟。

在进行1000次并发请求时，因为redis无法承受这么大的 IO，会主动进行中断连接，所以就没测了，不过由本轮测试可以看到 Redisson 的锁是起作用的。在高并发下，在实际生产中如果对于并发问题，可以考虑使用Redisson 来应对高并发问题，它能很好的解决分布式下多线程竞争资源问题。