面试必问的分布式锁，你懂了吗？-阿里云开发者社区

前言

分布式锁无论是在实际应用，还是面试中，都是经常会遇到的，因此很有必要掌握这个知识点。

今天跟大家一起探讨下当前主流的几种实现方案及其优缺点。

正文

为什么需要锁

原因其实很简单：因为我们想让同一时刻只有一个线程在执行某段代码。

因为如果同时出现多个线程去执行，可能会带来我们不想要的结果，可能是数据错误，也可能是服务宕机等等。

以淘宝双11为例，在0点这一刻，如果有几十万甚至上百万的人同时去查看某个商品的详情，这时候会触发商品的查询，如果我们不做控制，全部走到数据库去，那是有可能直接将数据库打垮的。

这个时候一个比较常用的做法就是进行加锁，只让1个线程去查询，其他线程待等待这个线程的查询结果后，直接拿结果。在这个例子中，锁用于控制访问数据库的流量，最终起到了保护系统的作用。

再举个例子，某平台做活动“秒杀茅台”，假如活动只秒杀1瓶，但是同时有10万人在同一时刻去抢，如果底层不做控制，有10000个人抢到了，额外的9999瓶平台就要自己想办法解决了。此时，我们可以在底层通过加锁或者隐式加锁的方式来解决这个问题。

此外，锁也经常用来解决并发下的数据安全方面的问题，这里就不一一举例了。

为什么需要分布式锁

分布式锁是锁的一种，通常用来跟 JVM 锁做区别。

JVM 锁就是我们常说的 synchronized、Lock。

JVM 锁只能作用于单个 JVM，可以简单理解为就是单台服务器（容器），而对于多台服务器之间，JVM 锁则没法解决，这时候就需要引入分布式锁。

实现分布式锁的方式

实现分布式锁的方式其实很多，只要能保证对于抢夺“锁”的系统来说，这个东西是唯一的，那么就能用于实现分布式锁。

举个简单的例子，有一个 MySQL 数据库 Order，Order库里有个 Lock 表只有一条记录，该记录有个状态字段 lock_status，默认为0，表示空闲状态，可以修改为1，表示成功获取锁。

我们的订单系统部署在100台服务器上，这100台服务器可以在“同一时刻”对上述的这1条记录执行修改，修改内容都是从0修改为1，但是 MysQL 会保证最终只会有1个线程修改成功。因此，这条记录其实就可以用于做分布式锁。

常见实现分布式锁的方式有：数据库、Redis、Zookeeper。

这其中又以Redis 最为常见。

Redis 实现分布式锁

加锁

加锁通常使用set 命令来实现，伪代码如下：

set key value PX milliseconds NX

几个参数的意义如下：

key、value：键值对

PX milliseconds：设置键的过期时间为 milliseconds 毫秒。

NX：只在键不存在时，才对键进行设置操作。SET key value NX 效果等同于 SETNX key value。

PX、expireTime 参数则是用于解决没有解锁导致的死锁问题。因为如果没有过期时间，万一程序员写的代码有 bug 导致没有解锁操作，则就出现了死锁，因此该参数起到了一个“兜底”的作用。

NX 参数用于保证在多个线程并发 set 下，只会有1个线程成功，起到了锁的“唯一”性。

解锁

解锁需要两步操作：

1）查询当前“锁”是否还是我们持有，因为存在过期时间，所以可能等你想解锁的时候，“锁”已经到期，然后被其他线程获取了，所以我们在解锁前需要先判断自己是否还持有“锁”

2）如果“锁”还是我们持有，则执行解锁操作，也就是删除该键值对，并返回成功；否则，直接返回失败。

由于当前Redis 还没有原子命令直接支持这两步操作，所以当前通常是使用 Lua 脚本来执行解锁操作，Redis 会保证脚本里的内容执行是一个原子操作。

脚本代码如下，逻辑比较简单：

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

两个参数的意义如下：

KEYS[1]：我们要解锁的 key

ARGV[1]：我们加锁时的 value，用于判断当“锁”是否还是我们持有，如果被其他线程持有了，value 就会发生变化。

上述方法是Redis 当前实现分布式锁的主流方法，可能会有一些小优区别，但是核心都是这个思路。看着好像没啥毛病，但是真的是这个样子吗？让我们继续往下看。

Redis 分布式锁过期了，还没处理完怎么办

为了防止死锁，我们会给分布式锁加一个过期时间，但是万一这个时间到了，我们业务逻辑还没处理完，怎么办？

首先，我们在设置过期时间时要结合业务场景去考虑，尽量设置一个比较合理的值，就是理论上正常处理的话，在这个过期时间内是一定能处理完毕的。

之后，我们再来考虑对这个问题进行兜底设计。

关于这个问题，目前常见的解决方法有两种：

1、守护线程“续命”：额外起一个线程，定期检查线程是否还持有锁，如果有则延长过期时间。Redisson 里面就实现了这个方案，使用“看门狗”定期检查（每1/3的锁时间检查1次），如果线程还持有锁，则刷新过期时间。

2、超时回滚：当我们解锁时发现锁已经被其他线程获取了，说明此时我们执行的操作已经是“不安全”的了，此时需要进行回滚，并返回失败。

同时，需要进行告警，人为介入验证数据的正确性，然后找出超时原因，是否需要对超时时间进行优化等等。

守护线程续命的方案有什么问题吗

Redisson 使用看门狗（守护线程）“续命”的方案在大多数场景下是挺不错的，也被广泛应用于生产环境，但是在极端情况下还是会存在问题。

问题例子如下：

1、线程1首先获取锁成功，将键值对写入 redis 的 master 节点

2、在 redis 将该键值对同步到 slave 节点之前，master发生了故障

3、redis 触发故障转移，其中一个 slave 升级为新的master

4、此时新的 master 并不包含线程1写入的键值对，因此线程2尝试获取锁也可以成功拿到锁

5、此时相当于有两个线程获取到了锁，可能会导致各种预期之外的情况发生，例如最常见的脏数据

解决方法：上述问题的根本原因主要是由于 redis 异步复制带来的数据不一致问题导致的，因此解决的方向就是保证数据的一致。

当前比较主流的解法和思路有两种：

1）Redis 作者提出的 RedLock；2）Zookeeper实现的分布式锁。

接下来介绍下这两种方案。

RedLock

首先，该方案也是基于文章开头的那个方案（set加锁、lua脚本解锁）进行改良的，所以 antirez 只描述了差异的地方，大致方案如下。

假设我们有N 个 Redis 主节点，例如 N = 5，这些节点是完全独立的，我们不使用复制或任何其他隐式协调系统，为了取到锁，客户端应该执行以下操作:

1、获取当前时间，以毫秒为单位。

2、依次尝试从5个实例，使用相同的 key 和随机值（例如UUID）获取锁。当向Redis请求获取锁时，客户端应该设置一个超时时间，这个超时时间应该小于锁的失效时间。例如你的锁自动失效时间为10秒，则超时时间应该在 5-50 毫秒之间。这样可以防止客户端在试图与一个宕机的Redis 节点对话时长时间处于阻塞状态。如果一个实例不可用，客户端应该尽快尝试去另外一个Redis实例请求获取锁。