什么是分布式锁

所谓当局者迷，旁观者清，先举个生活中的例子，就拿高铁举例，每辆高铁都有自己的运行路线，但这些路线可能会与其他高铁的路线重叠，如果只让高铁内部的司机操控路线，那就可能出现撞车事故，因为司机不知道其他高铁的运行路线是什么。所以，中控室就发挥作用了，中控室会监控每辆高铁，高铁在什么时间走什么样的路线全部由中控室指挥。

分布式锁就是基于这种思想实现的，它需要在我们分布式应用的外面使用一个第三方组件（可以是数据库、Redis、Zookeeper等）进行全局锁的监控，由这个组件决定什么时候加锁，什么时候释放锁。

在聊Redis如何实现分布式锁之前，我们要先聊一下redis的一个命令：setnx key value。我们知道，Redis设置一个key最常用的命令是：set key value，该命令不管key是否存在，都会将key的值设置成value，并返回成功：

基于setnx命令的特性，我们就可以实现一个最简单的分布式锁了。我们通过向Redis发送 setnx 命令，然后判断Redis返回的结果是否为1，结果是1就表示setnx成功了，那本次就获得锁了，可以继续执行业务逻辑；如果结果是0，则表示setnx失败了，那本次就没有获取到锁，可以通过循环的方式一直尝试获取锁，直至其他客户端释放了锁（delete掉key）后，就可以正常执行setnx命令获取到锁。流程如下：

针对上面的问题，我们可以基于setnx key value的基础上，同时给key设置一个过期时间。Redis已经提供了这样的命令：set key value ex seconds nx。其中，ex seconds 表示给key设置过期时间，单位为秒，nx 表示该set命令具备setnx的特性。效果如下：

要解决上面的问题，最省事的做法就是把锁的过期时间设置长一点，要远大于业务处理时间，但这样就会严重影响系统的性能，假如一台服务器在释放锁之前宕机了，而锁的超时时间设置了一个小时，那么在这一个小时内，其他线程访问这个服务时就一直阻塞在那里。所以，一般不推荐使用这种方式。

另一种解决方法就是在set key value ex seconds nx时，把value设置成一个唯一值，每个线程的value都不一样，在删除key之前，先通过get key命令得到value，然后判断value是否是自己线程生成的，如果是，则删除掉key释放锁，如果不是，则不删除key。正常流程如下：

针对上述Redis原始命令无法满足部分业务原子性操作的问题，Redis提供了Lua脚本的支持。Lua脚本是一种轻量小巧的脚本语言，它支持原子性操作，Redis会将整个Lua脚本作为一个整体执行，中间不会被其他请求插入，因此Redis执行Lua脚本是一个原子操作。

在上面的流程中，我们把get key value、判断value是否属于当前线程、删除锁这三步写到Lua脚本中，使它们变成一个整体交个Redis执行，改造后流程如下：

既然Lua脚本可以在释放锁时使用，那肯定也能在加锁时使用，而且一般情况下，推荐使用Lua脚本，因为在使用上面set key value ex seconds nx命令加锁时，并不能做到重入锁的效果，也就是当一个线程获取到锁后，在没有释放这把锁之前，当前线程自己也无法再获得这把锁，这显然会影响系统的性能。使用Lua脚本就可以解决这个问题，我们可以在Lua脚本中先判断锁（key）是否存在，如果存在则再判断持有这把锁的线程是否是当前线程，如果不是则加锁失败，否则当前线程再次持有这把锁，并把锁的重入次数+1。在释放锁时，也是先判断持有锁的线程是否是当前线程，如果是则将锁的重入次数-1，直至重入次数减至0，即可删除该锁（key）。