分布式锁（三）——基于redis的分布式锁实例

之前介绍分布式锁的时候，给过一个漫画介绍分布式锁的链接，传送门——漫画说明分布式锁这篇总结写的确实不错。但是有些地方我们可以按照其他思路来进行实现。

这里先需要了解一下各种失败机制，failover,failsafe,failfast,failback,forking。

整体介绍

如果要实现一个锁的机制，无非就是加锁，释放锁，已经其他异常场景下的几种处理。在redis下如何实现这些操作还是值得探讨的。

加锁

老版本的redis可以通过setnx命令来实现分布式锁（本篇博客也会采用这种方式）setnx命令文档，这个命令在key已经存在的情况下会返回0，在key不存在的情况下才会返回1，至于key所对应的value，这个根据业务随意就好。

解锁

解锁就很简单了，直接del指定的key值就可以了

异常场景的处理

锁超时

如果一个得到锁的线程在执行任务的过程中遇到了异常，来不及显示的释放分布式锁，则这个资源就会被永远锁住，这个是要处理的。可以给redis中指定的key设置一个过期时间，就可以解决这一问题，不过个人觉得设置一个标志位似乎更加合理一点。

在高一点的redis版本中可以通过set命令设置过期时间。

误删

在设置了过期时间之后，如果一个进程A执行很慢，在规定时间中没有顺利执行完指定的业务逻辑代码，锁就被释放了，之后进程B获得了锁（这个锁key值相同，但是value值不同）。进程B执行一段时间之后，进程A如果没有做value值的判断，则会删除进程B的分布式锁。因此在释放锁的时候，需要判断一下value值。

这里只是简单的列举了两个问题，造成这些问题的原因无非就一个——加锁/解锁+业务操作的原子性。

简单版本

先上一个简单的版本，我们利用setNx获取锁。

 /*
 * 基于redis的分布式锁
 * @param productLockDto
 * @return
 */
@Transactional(rollbackFor = Exception.class)
public int updateStockRedisLock(ProductLockDto productLockDto){
    int result = 0;
    final String key = String.format("redis_lock_product_id:%s",productLockDto.getId());
    String value = UUID.randomUUID().toString()+System.nanoTime();
    //利用setNx操作建立锁。
    Boolean res = stringRedisTemplate.opsForValue().setIfAbsent(key,value);
    if(res){
        //开始核心的业务逻辑处理
        ProductLock productLockEntity = lockMapper.selectByPrimaryKey(productLockDto.getId());
        if(productLockEntity!=null && productLockEntity.getStock().compareTo(productLockDto.getStock())>=0){
            productLockEntity.setStock(productLockDto.getStock());
            //与普通的更新操作相比，仅仅是增加了版本号的统计
            result = lockMapper.updateStockForNegative(productLockEntity);

            if(result>0){
                log.info("通过redis的分布式锁更新成功，剩余库存stock={}",productLockDto.getStock());
            }
        }
    }
    return result;
}

但是比较恶心的是，这里没有释放锁的操作，因此只能获取一次锁，然后操作一次，之后并没有释放锁，导致系统只能更新一次数据。日志如下所示：

数据库中也只是显示更新一次

正确释放锁

上述的代码中没有释放锁的操作，导致是有一个进程能对数据进行操作，但是在整体介绍部分说过，在释放锁之前需要对比一下redis锁的key值，避免出现进程A删除进程B对应的分布式锁的key值。

/* 
* 基于redis的分布式锁
 * @param productLockDto
 * @return
 */
@Transactional(rollbackFor = Exception.class)
public int updateStockRedisLock(ProductLockDto productLockDto){
    int result = 0;
    final String key = String.format("redis_lock_product_id:%s",productLockDto.getId());
    String value = UUID.randomUUID().toString()+System.nanoTime();
    //利用setNx操作建立锁。
    Boolean res = stringRedisTemplate.opsForValue().setIfAbsent(key,value);
    try{
        if(res){
            //真正的更新操作
            ProductLock productLockEntity = lockMapper.selectByPrimaryKey(productLockDto.getId());
            if(productLockEntity!=null && productLockEntity.getStock().compareTo(productLockDto.getStock())>=0){
                productLockEntity.setStock(productLockDto.getStock());
                //与普通的更新操作相比，仅仅是增加了版本号的统计
                result = lockMapper.updateStockForNegative(productLockEntity);

                if(result>0){
                    log.info("通过redis的分布式锁更新成功，剩余库存stock={}",productLockEntity.getStock());
                }
            }
        }
        //失败了就失败了，这里什么都没做。
    }catch (Exception e){
        log.error("出现异常，异常信息为:{}",e.fillInStackTrace());
    }finally {//无论如何，这里都需要释放锁。
        String redisValue = stringRedisTemplate.opsForValue().get(key);
        if(value.equals(redisValue)){//之前分析过，为了避免出现进程A删掉进程B的Key，这里需要做一个判断
            stringRedisTemplate.delete(key);
        }
    }
    return result;
}

引入了try-finally语句块，这样就能保证在任何时候都能释放锁，在释放锁的时候进行了一个必要的判断，这样能正确处理数据。同样用jmeter模拟2000个线程之后，数据如下。

锁正确释放之后，多个进程能进行数据操作。

2000个进程，最终只是500多个进程抢到了锁，因为我们采取了failover的机制。有些业务场景中，我们需要让这些获取锁失败的进程进行一个轮询，然后再次加入锁的竞争中。

轮询获取锁

先直接上实例吧

/*
 * 基于redis的分布式锁
 *
 * @param productLockDto
 * @return
 */
@Transactional(rollbackFor = Exception.class)
public int updateStockRedisLock(ProductLockDto productLockDto) {
    int result = 0;
    final String key = String.format("redis_lock_product_id:%s", productLockDto.getId());
    Boolean res = true;//利用一个标志位。根据标志位不断轮询判断
    while (res) {
        String value = UUID.randomUUID().toString() + System.nanoTime();
        //利用setNx操作建立锁。
        res = stringRedisTemplate.opsForValue().setIfAbsent(key, value);
        if (res) {
            try {
                res = false;//将标志位置为false,为了后续跳出循环
                //真正的更新操作
                ProductLock productLockEntity = lockMapper.selectByPrimaryKey(productLockDto.getId());
                int recordStock = productLockEntity.getStock();
                if (productLockEntity != null && productLockEntity.getStock().compareTo(productLockDto.getStock()) >= 0) {
                    productLockEntity.setStock(productLockDto.getStock());
                    //与普通的更新操作相比，仅仅是增加了版本号的统计
                    result = lockMapper.updateStockForNegative(productLockEntity);

                    if (result > 0) {
                        log.info("通过redis的分布式锁更新成功，剩余库存stock={}", recordStock - 1);
                    }
                }
            } catch (Exception e) {
                log.error("出现异常，异常信息为:{}", e.fillInStackTrace());
            } finally {
                String redisValue = stringRedisTemplate.opsForValue().get(key);
                if (value.equals(redisValue)) {//之前分析过，为了避免出现进程A删掉进程B的Key，这里需要做一个判断
                    stringRedisTemplate.delete(key);
                }
            }
        }else{
            res=true;//让获取分布式锁失败的线程继续获取锁。
        }
    }
    return result;
}

这个版本中提现了轮询的思想，这个在JDK中可重入锁的源码中有很多体现。这里不再赘述，具体数据结果如下（2000个线程，需要适当扩大数据库连接池的配置）

可以看到每个请求均正常获取到相关数据。模拟的2000个线程均正常更新了数据。

总结

本篇博客简单总结了redis中分布式锁的实践，篇实战，没啥可总结的。