Redis高并发分布式锁实战

案例：

简单的模拟多线程同时抢购一件商品的场景。

一、环境搭建

在springBoot中引入redis依赖​

  
        
            org.springframework.boot
            spring-boot-starter-data-redis
            
            2.1.8.RELEASE
        
        
        
            org.springframework.boot
            spring-boot-starter-cache
        

 

二、编写controller,用于处理减库存业务

1、版本一：直接获取商品库存，进行if判断，然后设置库存来操作减库存流程

@RestController
@RequestMapping("/myredis")
public class MyRedisController {
    
    @Autowired
    StringRedisTemplate stringRedisTemplate;
​
    @RequestMapping("/stock/{id}")
    public ResponseEntity reduceStock(@PathVariable int id){
        String key = "stock:"+id;
        //获取货物库存
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
        //检测库存是否小于等于0，如果是则提示库存不足
        if(stock<=0){
            System.out.println(Thread.currentThread().getName()+"库存不足！"+stringRedisTemplate.opsForValue().get(key));
            return  new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
        }
        //处理减库存业务
        stringRedisTemplate.opsForValue().set(key,String.valueOf(stock-1));
        return new ResponseEntity("减库存成功！", HttpStatus.OK);
    }
}

浏览器或者请求工具调用接口/myredis/stock/1001 来减指定id(1001) 编号的货物库存。

版本1中对该接口只是简单的获取指定id的库存，然后判断再设置减库存后的值。这种模式在高并发的情况下肯定会出现超卖的现象。假设多个线程同时的拿到最后一个商品，stock值都是一样的，判断stock>0之后就进行减1的操作，再将剩余的结果存放到redis中，这就会引起超卖的现象。

 

2、版本二：采用加锁synchronized

可以在代码块上加synchronized锁。

@RestController
@RequestMapping("/myredis")
public class MyRedisController {
    
    @Autowired
    StringRedisTemplate stringRedisTemplate;
​
    @RequestMapping("/stock/{id}")
    public ResponseEntity reduceStock(@PathVariable int id){
       
        String key = "stock:"+id;
        synchronized(this){
           //获取货物库存
           int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
           //检测库存是否小于等于0，如果是则提示库存不足
           if(stock<=0){
              System.out.println(Thread.currentThread().getName()+"库存不 
              足！"+stringRedisTemplate.opsForValue().get(key));
            return  new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
        }
           //处理减库存业务
           stringRedisTemplate.opsForValue().set(key,String.valueOf(stock-1));
        }
        return new ResponseEntity("减库存成功！", HttpStatus.OK);
     
    }
}

说明下问题，加锁的在高并发场景下对性能并不是特别好，因为其互斥性，可能会导致过多的线程排队等候，系统开销也比较大，不建议使用，并且在分布式环境下，使用synchronized关键字就不管用了，会出现分布式问题。

 

3、版本三：采用分布式锁setnx

setnx命令的语法： setnx key value

如果key存在，则不能设置成功，返回0（false），如果key不存在，那么久执行设置key，value。

 @RequestMapping("/stock/{id}")
    public ResponseEntity reduceStock(@PathVariable int id){
            //进来的线程必须要获取是否存在分布式锁
            String lockKey = "stock:"+id+":lockey";
            Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, lockKey);
            if (!flag) {
                return new ResponseEntity("服务器繁忙，请稍后重试", HttpStatus.NOT_ACCEPTABLE);
            }
        try {
            String key = "stock:" + id;
            //获取货物库存
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
            //检测库存是否小于等于0，如果是则提示库存不足
            if (stock <= 0) {
                return new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
            }
            //处理减库存业务
            stringRedisTemplate.opsForValue().set(key, String.valueOf(stock - 1));
            return new ResponseEntity("减库存成功！", HttpStatus.OK);
        }finally {
                //最后必须释放分布式锁，让下个线程获取
                stringRedisTemplate.delete(lockKey);
            }
        }
    }

上面采用了setnx命令，假设线程1、线程2、线程3同时访问这个扣减库存接口，那么同时想要去执行setIfAbsent方法（实际上就是setnx命令）。因为redis是单线程模型，所以无论要执行多少条命令，都是按照请求到达的先后顺序进行排队的，redis会把所有待执行的命令按先后顺序排在队列中：

 

故此，不管有多少个线程同时执行，对应的分布式锁有且仅有一个成功上锁！ 所以上面的方法成功的解决了超卖的问题。并且注意到上面对成功加锁的线程才处理业务，如果处理业务期间抛出异常，最终都会执行finally块来释放分布式锁，这很重要！

如果不释放分布式锁，那么之后的线程就会一直访问不了！除非手动的去redis服务器中删除分布式锁，故此为了避免执行过程抛异常，要在finally块释放锁！

 

 

3.2 分布式锁设置过期时间

上面的方法仍然会出现一些严重的bug。有下面一场景：

假设你处于高并发场景下，线程1刚刚好加上分布式锁，执行减库存业务逻辑，此时刚刚获取完库存即将进行减库存的时刻，突然redis服务器宕机了，那么就会导致一个问题，刚刚加上的分布式锁就会永久的残留在redis服务器中!

因为没有对分布式锁做超时过期处理 ，故此我们要将锁加上超时时间来修复这个bug，这样即使redis服务器宕机了，也不会说这个分布式锁永远残留在redis服务器中的现象。

 @RequestMapping("/stock/{id}")
    public ResponseEntity reduceStock(@PathVariable int id){
            //进来的线程必须要获取是否存在分布式锁
            String lockKey = "stock:"+id+":lockey";
            Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, lockKey);
            //为分布式锁设置过期时间
            stringRedisTemplate.expire(lockKey,10,TimeUnit.SECONDS);
            if (!flag) {
                return new ResponseEntity("服务器繁忙，请稍后重试", HttpStatus.NOT_ACCEPTABLE);
            }
        try {
            String key = "stock:" + id;
            //获取货物库存
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
            //检测库存是否小于等于0，如果是则提示库存不足
            if (stock <= 0) {
                return new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
            }
            //处理减库存业务
            stringRedisTemplate.opsForValue().set(key, String.valueOf(stock - 1));
            return new ResponseEntity("减库存成功！", HttpStatus.OK);
        }finally {
                stringRedisTemplate.delete(lockKey);
        }
    }

如果细心一点去想一下，其实上面设置超时时间的做法是不完美的，那万一你在执行完setIfAbsent，也就是刚刚设置完分布式锁，还没来得及设置过期时间的时候，突然redis宕机了怎么办呢？

针对上面的情况，在stringRedisTemplate中，我们可以直接使用下面的命令

 stringRedisTemplate.opsForValue().setIfAbsent(lockKey,lockKeyValue,10,TimeUnit.SECONDS);

这条命令在spring-boot-starter-data-redis 2.1.x版本才存在喔！

这条命令就将设置分布式锁和超时时间合成了一个原子操作，也就是一条执行命令，保证设置上过期时间。

 

更进一步思考

即使你为分布式锁加上了过期时间，但仍然会出现bug。假设有三个线程

• 线程a 首先加上了分布式锁 ，按照上面的代码逻辑分布时锁key和value都是一样的。 然后线程a由于网络原因，其任务要执行15s。但分布式锁只是设置了10秒的过期时间，所以当线程a执行完10s后，线程b在那个时刻刚好访问接口

• 线程b检测发现没有分布式锁，所以线程b进行加锁。然后执行b的逻辑。 假设线程b执行8s ，在线程a执行完后面的5s后，线程a紧接着要去执行finally块，去删除刚刚加的分布式锁（但是已经过期了!），线程a误以为这把锁时刚刚自己加的，原因是分布式锁按照上面的逻辑，不管是哪个线程，都是加到同样的key和value，此时删的就是线程b加的分布式锁，而线程b还在执行业务逻辑！

• 这个时候，恰巧线程c也访问到了这个接口，线程c发现没有分布式锁（实际上被a删了，但b还在执行！），故此c线程加锁，然后执行逻辑。然后线程b执行完了之后，如果c线程没执行完，那么b线程删的就是c线程加的分布式锁！

经过上面的分析，发现如果处于高并发，且网络有延时的情况，就可能会导致分布式锁失效问题，而且可能是永久失效！

3.3 解决分布式锁失效问题

我们想要只允许当前线程去释放自己加的分布式锁，不允许其他线程随意的删除其他线程加的锁，那么就要给锁加一个标志，比如我们给分布式锁使用uuid生成一个当前线程对应的序列号，并设置到分布式锁对应的value中，那么当要释放锁的时候，就要先去检测一下分布式锁的key对应的value是否是当前线程枷锁前生成的序列号值，如果，是才允许释放锁。

 @RequestMapping("/stock/{id}")
    public ResponseEntity reduceStock(@PathVariable int id){
        //进来的线程必须要获取是否存在分布式锁
            String lockKey = "stock:"+id+":lockey";
            String lockKeyValue = UUID.randomUUID().toString();
​
            Boolean flag = stringRedisTemplate.opsForValue().setIfAbsent(lockKey, lockKeyValue,10,TimeUnit.SECONDS);
            //为分布式锁设置过期时间
            if (!flag) {
                //设置失败，返回
                System.out.println(Thread.currentThread().getName() + "服务器繁忙，请稍后重试");
                return new ResponseEntity("服务器繁忙，请稍后重试", HttpStatus.NOT_ACCEPTABLE);
            }
        try {
            //首先用分布式锁，查看是否存在锁
            String key = "stock:" + id;
            //获取货物库存
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
            //检测库存是否小于等于0，如果是则提示库存不足
            if (stock <= 0) {
                System.out.println(Thread.currentThread().getName() + "库存不足！" + stringRedisTemplate.opsForValue().get(key));
                return new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
            }
            //处理减库存业务
            stringRedisTemplate.opsForValue().set(key, String.valueOf(stock - 1));
            return new ResponseEntity("减库存成功！", HttpStatus.OK);
        }finally {
            if(lockKeyValue.equals(stringRedisTemplate.opsForValue().get(lockKey))){
                stringRedisTemplate.delete(lockKey);
            }
        }
    }

上面的代码还是会存在一个问题。如果一个线程执行时间有超过了锁过期时间，别的线程依旧能够加锁。这种解决办法通常是设置一个定时器进行锁的续期。

假设线程a，加了把分布式锁，设置过期10s，但是它却要执行30s，当他执行到10s，锁就没了，其他线程可以随意加锁，放到抢购环境下，就会出现超卖问题！ 那么解决这种现象，我们为每一个加锁的线程，设置一个定时器，定期的去轮询当前线程是否执行完任务，判断是否执行完成的标准是查看是否存在分布式锁，如果检测发现存在分布式锁，那就将锁的过期时间延长，如果没有发现该线程对应的分布式锁，说明任务已经完成了，结束定时任务。这样来就能保证线程执行完成，分布式锁依然存在。

实际上市面上有很多成熟的框架用以支持分布式锁，比如我们的redission，这套框架可以很简单的实现上面我们加分布式锁的流程。

 

4、使用redisson实现分布式锁

       
            org.redisson
            redisson
            3.11.3
        

在配置类中往spring容器加入redis对象，下面是使用单台redis服务器的，当然redisson可以支持哨兵模式，redis集群等等api。

  @Bean
    public Redisson redisson(){
        Config config = new Config();
        //设置redis服务器连接地址，并设置服务器的redis数据库
        config.useSingleServer().setAddress("redis://localhost:6379").setDatabase(0);
        //调用Redisson静态构造方法创建redisson对象
        return (Redisson)Redisson.create(config);
    }

修改controller方法如下：

    @RequestMapping("/stock/{id}")
    public ResponseEntity reduceStock(@PathVariable int id) throws InterruptedException {
        //进来的线程必须要获取是否存在分布式锁
        String lockKey = "stock:"+id+":lockey";
        //redission加锁，注意这里只用传一个lockKey，对应的value会在redisson后台自动加上唯一标志。
        RLock lock = redisson.getLock(lockKey);
        lock.lock();
        try {
            //首先用分布式锁，查看是否存在锁
            String key = "stock:" + id;
            //获取货物库存
            int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
            //检测库存是否小于等于0，如果是则提示库存不足
            if (stock <= 0) {
                System.out.println(Thread.currentThread().getName() + "库存不足！" + stringRedisTemplate.opsForValue().get(key));
                return new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
            }
            //处理减库存业务
            stringRedisTemplate.opsForValue().set(key, String.valueOf(stock - 1));
            return new ResponseEntity("减库存成功！", HttpStatus.OK);
        }finally {
            lock.unlock();
        }
    }

要看懂上面的代码，首先了解下redisson加分布式锁后端逻辑

 

假设线程1和线程2同时访问接口，线程1先调用了redission的lock接口，而线程2迟一步调用

• 此时线程1就开始执行扣减库存的业务操作，并且redisson会为线程1开启一个线程，每个1/3的过期时间（redisson默认的过期时间是30s，1/3过期时间则为10s轮询一次），就会去轮询访问是否该分布式锁还存在，如果存在则进行续期。

• 那么在线程1执行它的减库存任务时，线程2会一直因为lock而阻塞着，直到线程1执行完毕，线程2才可以访问。（当然你也可以使用lock.tryLock方法直接让加不了锁的线程直接返回）

当然线程1处理完业务逻辑后，就会进行lock.unlock，此时不必去担心，是否别的线程会干掉线程1加的分布式锁，这些redisson已经帮我们解决了。

 

更进一步思考

问题一：redis集群下，主节点宕机，从节点未同步分布式锁，导致超卖

上面代码使用redisson改造后的代码，已经可以实现比较完整的分布式锁了，在单题redis服务的情况下，不会出现超卖的情况。但是如果时在redis集群架构的情况，还是会出现问题。当你保存分布式锁的那台redis服务器挂掉后，如果你部署了哨兵模式，那就会将主redis节点替换成从redis节点，但是从redis节点还没有来的及将锁同步过去，此时如果有线程继续访问接口，那就会检测到没有分布式锁从而操作减库存业务！在分布式场景下，超卖问题依然会存在！

采用RedissonRedlock

当线程要加分布式锁的时候，我们可以同时向多个redis集群中的节点一起加该分布式锁，当超过半数的redis节点加锁成功的时候，才返回加锁成功。然后线程再进行下面的扣减库存操作，最后对加锁成功的节点当线程执行完成后，要释放分布式锁。

 

代码：

@RequestMapping("/stock/{id}")
public ResponseEntity reduceStock(@PathVariable int id) throws InterruptedException {
    //进来的线程必须要获取是否存在分布式锁
    String lockKey = "stock:"+id+":lockey";
    //这里需要自己实例化不同的redis实例的redisson客户端连接。
    RLock lock = redisson.getLock(lockKey);
    RLock lock2 = redisson2.getLock(lockkey);
    //根据多个RLock对象构建RedissonRedLock，最根本的差别在这
    RedissonRedLock redLock = new RedissonRedLock(lock,lock2);
    try {
        //首先用分布式锁，查看是否存在锁
        String key = "stock:" + id;
        //获取货物库存
        int stock = Integer.parseInt(stringRedisTemplate.opsForValue().get(key));
        //检测库存是否小于等于0，如果是则提示库存不足
        if (stock <= 0) {
            System.out.println(Thread.currentThread().getName() + "库存不足！" + stringRedisTemplate.opsForValue().get(key));
            return new ResponseEntity("库存不足！", HttpStatus.INTERNAL_SERVER_ERROR);
        }
        //处理减库存业务
        stringRedisTemplate.opsForValue().set(key, String.valueOf(stock - 1));
        return new ResponseEntity("减库存成功！", HttpStatus.OK);
    }finally {
        //最后释放redLock
        redLock.unlock();
    }
}

问题二：在高并发场景下，性能有瓶颈

redis本身时一个单线程模型，他会对请求先后排序执行命令，尽管redis的性能很高，可以达到每秒几万的qps。但是如果在一些大并发量的场景下，这些就不够用了，比方说抢购商品，同时有30w人抢购，那必然会遇到redis的一个性能瓶颈。

redis分布式锁天生就是与高并发相悖的。

采用分段锁思想（ConcurrentHashMap底层也是使用这个去提升性能的）

假设某件商瓶id为1001 库存为 1000 ， 如果我们直接的设置一个key = stock:1001 value=1000 去存的话，你在redis集群架构通过对hash取值之后，只会映射到固定的一个redis节点的槽点。最终存放的该库存数都集中于这台redis服务器上。

采用分段锁的思想就是，我们可以将这个商品的key划分成几段，每段存放一定的数量的该商品货物，比如可以将stock:1001划分如下：

• key = stock:1001:fragement1 value = 200

• key = stock:1001:fragement2 value = 200

• key = stock:1001:fragement3 value = 200

• key = stock:1001:fragement4 value = 200

• key = stock:1001:fragement5 value = 200

我们将这个商品的key和value平均分成5段，那么加分布式锁的时候，就可以按这个key的段去加，分散开来，这样性能就提升上去了！