分布式锁概述

分布式锁，是控制分布式系统之间同步访问共享资源的一种方式。

在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。

分布式锁的几种实现方式

  • 基于MySQL的分布式锁
  • 基于Redis的分布式锁
  • 基于ZooKeeper的分布式锁
  • 自研分布式锁:如谷歌的Chubby

本文介绍的是基于Redis的分布式锁。

基于Redis的分布式锁

分布式锁本质上要实现的目标就是在 Redis 里面占一个“茅坑”，当别的进程也要来占时，发现已经有人蹲在那里了，就只好放弃或者稍后再试。

占坑一般是使用 setnx(set if not exists) 指令，只允许被一个客户端占坑。先来先占，用完了，再调用del指令释放茅坑。

常规的基于Redis的分布式锁方案，用的Redis都是单节点的，但是单节点的有一种无法解决的问题（后面会讲到），基于这个问题，Redis的作者提供了一种通用的算法Redlock，他认为这种算法实现比普通的单节点实现更安全；下面我们一一来了解单节点的Redis分布式锁和Redlock算法。

基于单节点的Redis分布式锁

实现命令

我们先来看下正确的操作步骤，基于单节点的Redis分布式锁主要利用下面这条命令：

SET key_name my_random_value NX PX 30000

实现过程简述

首先，Redis客户端为了获取锁，向Redis节点发送上面这条命令，上面的命令如果执行成功，则代表客户端成功获取到了锁，接下来就可以访问共享资源了；而如果上面的命令执行失败，则说明获取锁失败。

客户端获取到锁，完成了对共享资源的操作之后，然后需要去释放锁。

在上面的SET命令中：

  • my_random_value是由客户端生成的一个随机字符串，它要保证在足够长的一段时间内在所有客户端的所有获取锁的请求中都是唯一的。
  • NX表示只有当key_name对应的key值不存在的时候才能SET成功。这保证了只有第一个请求的客户端才能获得锁，而其它客户端在锁被释放之前都无法获得锁。
  • PX 30000表示这个锁有一个30秒的自动过期时间。当然，这里30秒只是一个例子，大家可以根据业务情况选择合适的过期时间。

最后，当客户端完成了对共享资源的操作之后，需要执行下面的Redis Lua脚本来释放锁：

1
2
3
4
5
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

这段Lua脚本在执行的时候要把前面的my_random_value作为ARGV[1]的值传进去，把key_name作为KEYS[1]的值传进去。

上面的实现过程中几个重要的问题

锁可能永远得不到释放

第一个问题，这个锁必须要设置一个过期时间。否则的话，当一个客户端获取锁成功之后，假如执行业务操作时它崩溃了，或者由于发生了网络分割（network partition）导致它再也无法和Redis节点通信了，那么它就会一直持有这个锁，而其它客户端永远无法获得锁了。获得锁的客户端必须在这个时间之内完成对共享资源的访问。

获取锁的操作

第二个问题，获取锁的操作，网上不少文章把它实现成了两个Redis命令：

1
2
SETNX resource_name my_random_value
EXPIRE resource_name 30

虽然这两个命令和前面算法描述中的一个SET命令执行效果相同，但却不是原子的。如果客户端在执行完SETNX后崩溃了，那么就没有机会执行EXPIRE了，导致它一直持有这个锁。Redis 2.8 版本中作者加入了SET指令的扩展参数（如上所示），使得 SETNX和EXPIRE指令可以一起执行。

给锁设置唯一字符串

第三个问题，设置一个随机字符串my_random_value是很有必要的，它保证了一个客户端释放的锁必须是自己持有的那个锁。假如获取锁时SET的不是一个随机字符串，而是一个固定值，那么可能会发生下面的执行序列：

  1. 客户端1获取锁成功。
  2. 客户端1在某个操作上阻塞了很长时间。
  3. 过期时间到了，锁自动释放了。
  4. 客户端2获取到了对应同一个资源的锁。
  5. 客户端1从阻塞中恢复过来，释放掉了客户端2持有的锁。

之后，客户端2在访问共享资源的时候，就没有锁为它提供保护了；所以必须保证了一个客户端释放的锁必须是自己持有的那个锁。

释放锁的操作

第四个问题，释放锁的操作必须使用Lua脚本来实现。我们上面说到，必须给锁设置唯一的字符串，保证客户端释放的锁必须是自己持有的那个锁。

这样释放锁其实包含三步操作：GET锁的唯一字符串、判断是否匹配和DEL锁，需要用Lua脚本来实现能保证这三步的原子性。否则，如果把这三步操作放到客户端逻辑中去执行的话，就有可能发生与前面第三个问题类似的执行序列：

  1. 客户端1获取锁成功。
  2. 客户端1访问共享资源。
  3. 客户端1为了释放锁，先执行GET操作获取随机字符串的值。
  4. 客户端1判断随机字符串的值，与预期的值相等。
  5. 客户端1由于某个原因阻塞住了很长时间。
  6. 过期时间到了，锁自动释放了。
  7. 客户端2获取到了对应同一个资源的锁。
  8. 客户端1从阻塞中恢复过来，执行DEL操纵，释放掉了客户端2持有的锁。

实际上，在上述第三个问题和第四个问题的分析中，如果不是客户端阻塞住了，而是出现了大的网络延迟，也有可能导致类似的执行序列发生。

单节点Redis分布式锁无法解决的问题

前面的四个问题，只要实现分布式锁的时候加以注意，就都能够被正确处理。但除此之外，Redis的作者antirez还指出了一个问题，是由failover引起的，却是基于单Redis节点的分布式锁无法解决的。正是这个问题催生了Redlock的出现。

这个问题是这样的。假如单节点Redis宕机了，那么所有客户端就都无法获得锁了，服务变得不可用。为了提高可用性，我们可以给这个Redis节点挂一个Slave，当Master节点不可用的时候，系统自动切到Slave上（failover）。但由于Redis的主从复制（replication）是异步的，这可能导致在failover过程中丧失锁的安全性。考虑下面的执行序列：

  1. 客户端1从Master获取了锁。
  2. Master宕机了，存储锁的key还没有来得及同步到Slave上。
  3. Slave升级为Master。
  4. 客户端2从新的Master获取到了对应同一个资源的锁。

于是，客户端1和客户端2同时持有了同一个资源的锁。锁的安全性被打破。针对这个问题，Redis的作者antirez设计了Redlock算法。

有效时间问题

另外，前面这个算法中出现的锁的有效时间(lock validity time)，设置成多少合适呢？

如果设置太短的话，锁就有可能在客户端完成对于共享资源的访问之前过期，从而失去保护；如果设置太长的话，一旦某个持有锁的客户端释放锁失败，那么就会导致所有其它客户端都无法获取锁，从而长时间内无法正常工作。

所以分布式锁的选择也要看具体的业务场景来具体操作。

RedLock算法

由于前面介绍的基于单Redis节点的分布式锁在故障切换的时候会产生解决不了的安全性问题，因此Redis的作者antirez提出了新的一种通用的分布式锁的算法Redlock，它基于N个完全独立的Redis节点（通常情况下N可以设置成5）。

运行Redlock算法的客户端依次执行下面各个步骤，来完成获取锁的操作：

  1. 获取当前时间（毫秒数）。
  2. 按顺序依次向N个Redis节点执行获取锁的操作。这个获取操作跟前面基于单Redis节点的获取锁的过程相同，包含随机字符串my_random_value，也包含过期时间(比如PX 30000，即锁的有效时间)。为了保证在某个Redis节点不可用的时候算法能够继续运行，这个获取锁的操作还有一个超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个Redis节点获取锁失败以后，应该立即尝试下一个Redis节点。这里的失败，应该包含任何类型的失败，比如该Redis节点不可用，或者该Redis节点上的锁已经被其它客户端持有（注：Redlock原文中这里只提到了Redis节点不可用的情况，但也应该包含其它的失败情况）。
  3. 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数Redis节点（>= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间(lock validity time)，那么这时客户端才认为最终获取锁成功；否则，认为最终获取锁失败。
  4. 如果最终获取锁成功了，那么这个锁的有效时间应该重新计算，它等于最初的锁的有效时间减去第3步计算出来的获取锁消耗的时间。
  5. 如果最终获取锁失败了（可能由于获取到锁的Redis节点个数少于N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端应该立即向所有Redis节点发起释放锁的操作（即前面介绍的Redis Lua脚本）。

当然，上面描述的只是获取锁的过程，而释放锁的过程比较简单：客户端向所有Redis节点发起释放锁的操作，不管这些节点当时在获取锁的时候成功与否。

Redlock算法的安全性问题

由于N个Redis节点中的大多数能正常工作就能保证Redlock正常工作，因此理论上它的可用性更高。我们前面讨论的单Redis节点的分布式锁在failover的时候锁失效的问题，在Redlock中不存在了，但如果有节点发生崩溃重启，还是会对锁的安全性有影响的。

具体的影响程度跟Redis对数据的持久化程度有关。

假设一共有5个Redis节点：A, B, C, D, E；设想发生了如下的事件序列：

  1. 客户端1成功锁住了A, B, C，获取锁成功（但D和E没有锁住）。
  2. 节点C崩溃重启了，但客户端1在C上加的锁没有持久化下来，丢失了。
  3. 节点C重启后，客户端2锁住了C, D, E，获取锁成功。

这样，客户端1和客户端2同时获得了锁（针对同一资源）。

在默认情况下，Redis的AOF持久化方式是每秒写一次磁盘（即执行fsync），因此最坏情况下可能丢失1秒的数据。为了尽可能不丢数据，Redis允许设置成每次修改数据都进行fsync，但这会降低性能。当然，即使执行了fsync也仍然有可能丢失数据（这取决于系统而不是Redis的实现）。所以，上面分析的由于节点重启引发的锁失效问题，总是有可能出现的。

延迟重启

为了应对上面这个问题，antirez又提出了延迟重启(delayed restarts)的概念。也就是说，一个节点崩溃后，先不立即重启它，而是等待一段时间再重启，这段时间应该大于锁的有效时间(lock validity time)。这样的话，这个节点在重启前所参与的锁都会过期，它在重启后就不会对现有的锁造成影响。

释放锁

在最后释放锁的时候，antirez在算法描述中特别强调，客户端应该向所有Redis节点发起释放锁的操作。也就是说，即使当时向某个节点获取锁没有成功，在释放锁的时候也不应该漏掉这个节点。这是为什么呢？

设想这样一种情况，客户端发给某个Redis节点的获取锁的请求成功到达了该Redis节点，这个节点也成功执行了SET操作，但是它返回给客户端的响应包却丢失了。这在客户端看来，获取锁的请求由于超时而失败了，但在Redis这边看来，加锁已经成功了。因此，释放锁的时候，客户端也应该对当时获取锁失败的那些Redis节点同样发起请求。

实际上，这种情况在异步通信模型中是有可能发生的：客户端向服务器通信是正常的，但反方向却是有问题的。

Redission

Redission是Java语言实现的Redis客户端，是一个在Redis的基础上实现的Java驻内存数据网格。Redission底层采用的是netty框架，在分布式锁的实现上也提供了Redlock算法的实现。所以现在做基于Redis的分布式锁的话可以用Redission来实现。