Redis分布式锁的前世今生

背景

如今的服务大多数是集群化部署，这就使得像synchronized、ReentrantLock等传统的本地锁失去了功效。因此需要引入第三方的服务实现对这些并发进程的调度，从而控制对共享资源的访问，像redis、zookeeper、mysql等。其中又以redis的应用最为广泛。

分布式锁的要素

最重要的两个要素：排他性、容错性。

排他性是指在分布式应用集群中，同一个方法在同一时间内只能被一台机器上的一个线程执行。

容错性是指不论正常的业务执行完成，还是突发性的程序崩溃或者网络中断，都要保证分布式锁最终一定能得到释放，不能出现死锁现象。

redis分布式锁的基本命令

1、加锁 SETNX key value

setnx 的含义就是 SET if Not Exists，有两个参数 setnx(key, value)，该方法是原子性操作。如果 key 不存在，则设置当前 key 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。

2、解锁 del (key)

得到锁的线程执行完任务，需要释放锁，以便其他线程可以进入。

3、配置锁超时 expire (key，30s）

客户端崩溃或者网络中断，资源将会永远被锁住,即死锁，因此需要给key配置过期时间，以保证即使没有被显式释放，这把锁也要在一定时间后自动释放。

OK，有了上面的理论基础，我们就可以来逐步的揭开redis分布式锁的神秘面纱。

我们以常见的扣减库存的场景为例，当有线程来执行扣减库存的方法时，大致逻辑是先判断当前库存，如果还有库存的话，就库存减1，然后生成明细记录。

一把问题很多的锁

首先看一段伪代码。

methodA(){
//ID为666的商品库存扣减key
Stringkey="stock:deduct:666"

if（setnx（key，1）==1）{
expire(key,10,TimeUnit.SECONDS)
try {
//查询是否有库存
//扣减库存
//生成明细记录
      } finally {
del（key）
      }
  }else{
//获取锁失败，睡眠100毫秒，然后自旋调用本方法
methodA()
  }
}

这段代码的主要逻辑是，先给ID为666的商品库存上锁，然后设置key的过期时间为10秒，之后就执行扣减库存的逻辑了，等业务逻辑执行完成，就删除key释放锁。在此期间如果有其他线程来获取锁，会上锁失败，失败后就等一会再次调用methodA方法继续尝试上锁，然后循环往复，直到上锁成功。

看上去大功告成了，所谓的分布式锁也不过如此。

然而，正如我们标题上写的，这是一把问题很多的锁，有什么问题呢？

首先最大的问题是，多个命令之间不是原子操作。在setnx和expire之间是分了两步来执行的，如果setnx成功，但是expire却执行失败，或者还没有执行就突发宕机，就造成了这个资源的死锁，违反了我们上面提到的容错性原则。

另外存在的一个问题是，可能会出现线程A删掉了线程B的锁。假设有两个线程A和B，A先上锁成功开始执行业务逻辑，但由于某些原因导致A执行很慢，15秒才执行完，但A的锁有效期只有10秒，A锁过期后，B上锁成功，但是B还没有执行完业务逻辑，线程A业务逻辑执行完成，执行删锁操作，此时删除的，实际上是B的锁，B的锁删掉了，也就无法阻止其他线程来加锁，违反了上面提到的排他性原则。

如何解决这两个问题呢？

优化后的锁

第一个问题，既然多个命令之间不是原子操作，我们用一个命令就行了，而redis恰好也提供了一个这样的命令，setex，即在赋值的时候设置过期时间，这是一个原子命令。对应到java中，也有这样的API供我们使用：

redisTemplate.opsForValue().setIfAbsent("key","success",10,TimeUnit.SECONDS)

第二个问题，可以在删除锁之前做一个判断，验证当前要删除的锁是不是自己的锁，实现方式也很简单，可以将value值设置为当前的线程ID或者随便一个UUID。

优化后的伪代码应该是这样的：

methodA(){
//ID为666的商品库存扣减key
Stringkey="stock:deduct:666";
Stringvalue=Thread.currentThread().getId();

if（setex（key, 10, value）==1）{
try {
//查询是否有库存
//扣减库存
//生成明细记录
      } finally {
if(get(key).equals(value)){
del（key）
        }
      }
  }else{
//获取锁失败，睡眠100毫秒，然后自旋调用本方法
methodA()
  }
}

这把锁总没问题了吧？

然而，细细考究一下，还是会发现不妥之处。虽然我们删除锁的时候做了判断，但仍有可能删错锁。根本原因是判断锁和删除锁同样不是原子操作。

那到底如何保证绝对的原子性？

lua脚本的横空出世

这里我们不去深究lua脚本是什么，只需要知道，lua是一个脚本语言，redis执行lua脚本的时候，会将它里面的命令当做一个整体去执行，要么全部执行成功，要么出现异常，结果不会更新到redis中。

因此，上面的删锁操作，我们完全可以将判断命令和删除命令都放到lua脚本中，然后由代码去执行lua脚本，最终会实现我们想要的原子操作。

实际上，这也正是redis官方推荐的做法。具体可查看官方文档：​​set 命令 — Redis中国用户组（CRUG）​​。

这里提供一段java中调用lua脚本的代码，大家看了后可以加深理解：

Stringscript="if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
Integerresult=redisTemplate.execute(newDefaultRedisScript<>(script, Integer.class), Arrays.asList(lockKey), uuid);

其中的脚本代码是官方文档中提供的，可以直接复制过来使用。

原生分布式锁

综合上面所说的，一个完整的原生分布式锁应该就是下面这个样子了：

methodA(){
//ID为666的商品库存扣减key
Stringkey="stock:deduct:666";
Stringvalue=Thread.currentThread().getId();
Stringscript="if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
if（setex（key, 10, value）==1）{
try {
//查询是否有库存
//扣减库存
//生成明细记录
      } finally {
//解锁
Longresult=redisTemplate.execute( newDefaultRedisScript<>(script,Long.class),Arrays.asList(lockKey),uuid);
      }
  }else{
//获取锁失败，睡眠100毫秒，然后自旋调用本方法
methodA()
  }
}

这就是一个比较完善的分布式锁了，既满足了对共享资源的并发控制，又保证了加锁、解锁的原子性操作，防止突发状况造成的死锁问题。

这里大家再想一个问题，如何避免业务执行时间过长锁过期的问题？为了保证排他性，肯定要保证在业务执行时间内，锁是一定不能过期的。在原生的分布式锁中，没有什么好的方法，只能加长锁的过期时间，保证业务一定能执行完成。

那么，有没有更好的解决方案呢？

Hi，我叫redisson

redisson是redis官方推荐的一个分布式锁的框架，它帮我们解决了上面提到的所有问题，底层也是用了lua脚本实现，同时又提供了watchdog(看门狗)机制，在锁将要过期的时候，会自动检测业务是否执行完成，如果没有完成，则自动延长锁的过期时间，直到业务执行完成。而且最重要的一点，使用起来非常简单，几行代码就可以搞定，不像原生锁那样繁琐，是我们进行分布式锁开发的不二选择。这里不做详细描述了，感兴趣的可以在网上搜索一下。

好了，关于redis分布式锁就到这里了。