分布式计算原理之分布式协调与同步(1)——分布式锁

1:什么是分布式锁

在分布式互斥中，分布式互斥博客地址，讲述了同一时刻，同一个临界资源只能同一个进程访问，为了维护数据的一致性，防止分布式系统中的多个进程之间相互干扰，我们需要一种分布式协调技术（某种机制）来对这些进程进行调度，来保证只有满足某个条件的线程才能访问资源，不满足条件的线程只能等待，在下一轮竞争中重新满足条件时才能访问资源，这个分布式协调技术的核心就是来实现这个分布式锁。

这部分的分布式协调技术（机制），指的是为了实现分布式互斥，在某个地方做个标记，每个线程都可以看到这个标记，当标记不存在时，可以设置该标记，当标记被设置后，其他线程只能等待拥有该标记的线程执行完成，并释放该标记后，才能去设置该标记和访问临界资源。这里的标记，就是锁。

也就是说，锁是实现多线程同时访问同一临界资源，保证同一时刻只有一个线程可访问临界资源所做的一种标记。与普通锁不同的是，分布式锁是指分布式环境下，系统部署在多个机器中，实现多进程分布式互斥的一种锁。

为了保证多个进程能看到锁，锁被存在公共存储（比如 Redis、Memcache、数据库等三方存储中），以实现多个进程并发访问同一个临界资源，同一时刻只有一个进程可访问共享资源，确保数据的一致性。

2:使用分布式锁的场景

以电商为例，如果某家商户要售卖吹风机，库存只有 2 个，但有 5 个来自不同地区的用户{A,B,C,D,E}几乎同时下单，那么这 2 个吹风机到底究竟会被谁买到？在实际业务中，为了高并发地接收大量用户订单请求，电商网站往往采取不同的策略，比如有些电商根据下单时间判断谁可以购买成功，而有些电商则是根据付款时间来判断。

但无论采用什么样的规则去判断谁能购买成功，都必须要保证吹风机售出时，数据库中更新的库存是正确的。为了便于理解，以下单时间作为购买成功的判断依据。我们能想到的最简单方案就是，给吹风机的库存数加一个锁。当有一个用户提交订单后，后台服务器给库存数加一个锁，根据该用户的订单修改库存。而其他用户必须等到锁释放以后，才能重新获取库存数，继续购买。

在这里，吹风机的库存就是临界资源，不同的购买者对应着多个进程，后台服务器对临界资源加的锁就是告诉其他进程勿入。

但这里存在着严重的问题：用户 A 想买 1 个吹风机，用户 B 想买 2 个吹风机。在理想状态下，用户 A 网速好先买走了 1 个，库存还剩下 1 个，此时应该提示用户 B 库存不足，用户 B 购买失败。但实际情况是，用户 A 和用户 B 同时获取到商品库存还剩 2 个，用户 A 买走 1 个，在用户 A 更新库存之前，用户 B 又买走了 2 个，此时用户 B 更新库存，商品还剩 0 个。这时总共 2 个吹风机，却卖出去了 3 个。

因此，在高并发场景下，如果只使用单机锁将会出现不可预知的后果，为了保证临界资源同一时间只能被一个进程使用，从而确保数据的一致性，我们就需要引入分布式锁了。此外，在大规模分布式系统中，单个机器的线程锁无法管控多个机器对同一资源的访问，这时使用分布式锁，就可以把整个集群当作一个应用一样去处理，实用性和扩展性更好。

3: 分布式锁的三种实现方法及对比

• 基于数据库实现分布式锁，这里的数据库指的是关系型数据库
• 基于缓存实现分布式锁
• 基于 ZooKeeper 实现分布式锁

 

3.1: 基于数据库实现分布式锁

要实现分布式锁，最直接的方式就是创建一张锁表，然后通过操作该表中的数据来实现。

当我们要锁住某个资源时，就在该表中增加一条记录，想要释放锁的时候就删除这条记录。数据库对共享资源做了唯一性约束，如果有多个请求被同时提交到数据库的话，数据库会保证只有一个操作可以成功，操作成功的那个线程就获得了访问共享资源的锁，可以进行操作。

基于数据库实现的分布式锁，是最容易理解的。但是，因为数据库需要落到硬盘上，频繁读取数据库会导致 IO 开销大，因此这种分布式锁适用于并发量低，对性能要求低的场景。对于双 11、双 12 等需求量激增的场景，数据库锁是无法满足其性能要求的。而在平日的购物中，我们可以在局部场景中使用数据库锁实现对资源的互斥访问。

还是以电商卖吹风机的场景为例。吹风机库存是 2 个，有 3 个来自不同地区的用户{A,B,C}想要购买，其中用户 A 想买 1 个，用户 B 想买 2 个，用户 C 想买 1 个。

用户 A 和用户 B 几乎同时下单，但用户 A 的下单请求最先到达服务器。因此，该商家的产品数据库中增加了一条关于用户 A 的记录，用户 A 获得了锁，他的订单请求被处理，服务器修改吹风机库存数，减去 1 后还剩下 1 个。

当用户 A 的订单请求处理完成后，有关用户 A 的记录被删除，服务器开始处理用户 B 的订单请求。这时，库存只有 1 个了，无法满足用户 B 的订单需求，因此用户 B 购买失败。

从数据库中，删除用户 B 的记录，服务器开始处理用户 C 的订单请求，库存中 1 个吹风机满足用户 C 的订单需求。所以，数据库中增加了一条关于用户 C 的记录，用户 C 获得了锁，他的订单请求被处理，服务器修改吹风机数量，减去 1 后还剩下 0 个。

可以看出，基于数据库实现的分布式锁比较简易，绝招在于创建一张锁表，为申请者在锁表里建立一条记录，记录建立成功则获得锁，消除记录则释放锁。

该方法类似于集中式机制，依赖于数据库，主要有两个缺点：

1. 单点故障问题。一旦数据库不可用，会导致整个系统崩溃。
2. 死锁问题。数据库锁没有失效时间，未获得锁的进程只能一直等待已获得锁的进程主动释放锁。一旦已获得锁的进程挂掉或者解锁操作失败，会导致锁记录一直存在数据库中，其他进程无法获得锁。

3.2: 基于缓存实现分布式锁

数据库的性能限制了业务的并发量，对于高并发场景下，可以采用基于缓存实现分布式锁。

所谓基于缓存，也就是说把数据存放在计算机内存中，不需要写入磁盘，减少了 IO 读写，提高性能。

Redis 通常可以使用 setnx(key, value) 函数来实现分布式锁。key 和 value 就是基于缓存的分布式锁的两个属性，其中 key 表示锁 id，value = currentTime + timeOut，表示当前时间 + 超时时间。也就是说，某个进程获得 key 这把锁后，如果在 value 的时间内未释放锁，系统就会主动释放锁。

setnx 函数的返回值有 0 和 1：

• 返回 1，说明该服务器获得锁，setnx 将 key 对应的 value 设置为当前时间 + 锁的有效时间。
• 返回 0，说明其他服务器已经获得了锁，进程不能进入临界区。该服务器可以不断尝试 setnx 操作，以获得锁

 

还是以电商售卖吹风机的场景为例，假设现在库存数量是足够的。

用户 A 的请求因为网速快，最先到达 Server2，setnx 操作返回 1，并获取到购买吹风机的锁；用户 B 和用户 C 的请求，几乎同时到达了 Server1 和 Server3，但因为这时 Server2 获取到了吹风机数据的锁，所以只能加入等待队列。Server2 获取到锁后，负责管理吹风机的服务器执行业务逻辑，只用了 1s 就完成了订单。订单请求完成后，删除锁的 key，从而释放锁。此时，排在第二顺位的 Server1 获得了锁，可以访问吹风机的数据资源。但不巧的是，Server1 在完成订单后发生了故障，无法主动释放锁。

于是，排在第三顺位的 Server3 只能等设定的有效时间（比如 30 分钟）到期，锁自动释放后，才能访问吹风机的数据资源，也就是说用户 C 只能到 00:30:01 以后才能继续抢购。

 

总结来说，Redis 通过队列来维持进程访问共享资源的先后顺序。Redis 锁主要基于 setnx 函数实现分布式锁，当进程通过 setnx<key,value> 函数返回 1 时，表示已经获得锁。排在后面的进程只能等待前面的进程主动释放锁，或者等到时间超时才能获得锁。

相对于基于数据库实现分布式锁的方案来说，基于缓存实现的分布式锁的优势表现在以下几个方面：

• 性能更好。数据被存放在内存，而不是磁盘，避免了频繁的 IO 操作；
• 很多缓存可以跨集群部署，避免了单点故障问题；
• 很多缓存服务都提供了可以用来实现分布式锁的方法，比如 Redis 的 setnx 方法等；
• 可以直接设置超时时间来控制锁的释放，因为这些缓存服务器一般支持自动删除过期数据

缺点：通过超时时间来控制锁的失效时间，并不是十分靠谱，因为一个进程执行时间可能比较长，或受系统进程做内存回收等影响，导致时间超时，从而不正确地释放了锁。

 

3.3：基于ZooKeeper 实现分布式锁

ZooKeeper 基于树形数据存储结构实现分布式锁，来解决多个进程同时访问同一临界资源时，数据的一致性问题。ZooKeeper 的树形数据存储结构主要由 4 种节点构成。

• 持久节点。这是默认的节点类型，一直存在于 ZooKeeper 中；
• 持久顺序节点。也就是说，在创建节点时，ZooKeeper 根据节点创建的时间顺序对节点进行编号；
• 临时节点。与持久节点不同，当客户端与 ZooKeeper 断开连接后，该进程创建的临时节点就会被删除；
• 临时顺序节点，就是按时间顺序编号的临时节点

 

根据它们的特征，ZooKeeper 基于临时顺序节点实现了分布锁：

还是以电商售卖吹风机的场景为例。假设用户 A、B、C 同时在 双11零点整提交了购买吹风机的请求，ZooKeeper 会采用如下方法来实现分布式锁：

1. 在与该方法对应的持久节点 shared_lock 的目录下，为每个进程创建一个临时顺序节点。如下图所示，吹风机就是一个拥有 shared_lock 的目录，当有人买吹风机时，会为他创建一个临时顺序节点。
2. 每个进程获取 shared_lock 目录下的所有临时节点列表，注册子节点变更的 Watcher，并监听节点。
3. 每个节点确定自己的编号是否是 shared_lock 下所有子节点中最小的，若最小，则获得锁。例如，用户 A 的订单最先到服务器，因此创建了编号为 1 的临时顺序节点 LockNode1。该节点的编号是持久节点目录下最小的，因此获取到分布式锁，可以访问临界资源，从而可以购买吹风机
4. 。若本进程对应的临时节点编号不是最小的，则分为两种情况：
   1. a.  本进程为读请求，如果比自己序号小的节点中有写请求，则等待；
   2. b.  本进程为写请求，如果比自己序号小的节点中有读请求，则等待。

例如，用户 B 也想要买吹风机，但在他之前，用户 C 想看看吹风机的库存量。因此，用户 B 只能等用户 A 买完吹风机、用户 C 查询完库存量后，才能购买吹风机。

 

3.4：三种实现方式对比

 

这里的实现复杂性，是针对同样的分布式锁的实现复杂性，与之前提到的基于数据库的实现非常简易不一样。基于数据库实现的分布式锁存在单点故障和死锁问题，仅仅利用数据库技术去解决单点故障和死锁问题，是非常复杂的。而 ZooKeeper 已定义相关的功能组件，因此可以很轻易地解决设计分布式锁时遇到的各种问题。所以说，要实现一个完整的、无任何缺陷的分布式锁，ZooKeeper 是一个最简单的选择。

总结来说，ZooKeeper 分布式锁的可靠性最高，有封装好的框架，很容易实现分布式锁的功能，并且几乎解决了数据库锁和缓存式锁的不足，因此是实现分布式锁的首选方法。

 

从上述分析可以看出，为了确保分布式锁的可用性，我们在设计时应考虑到以下几点：

1. 互斥性，即在分布式系统环境下，分布式锁应该能保证一个资源或一个方法在同一时间只能被一个机器的一个线程或进程操作。
2. 具备锁失效机制，防止死锁。即使有一个进程在持有锁的期间因为崩溃而没有主动解锁，也能保证后续其他进程可以获得锁。
3. 可重入性，即进程未释放锁时，可以多次访问临界资源。
4. 有高可用的获取锁和释放锁的功能，且性能要好。

 

4：问题延伸

4.1：何解决分布式锁的羊群效应问题？

在分布式锁问题中，会经常遇到羊群效应。羊群效应指的是在整个分布式锁的竞争过程中，大量的“Watcher 通知”和“子节点列表的获取”操作重复运行，并且大多数节点的运行结果都是判断出自己当前并不是编号最小的节点，继续等待下一次通知，而不是执行业务逻辑。这就会对 ZooKeeper 服务器造成巨大的性能影响和网络冲击。更极端的是，如果同一时间多个节点对应的客户端完成事务或事务中断引起节点消失，ZooKeeper 服务器就会在短时间内向其他客户端发送大量的事件通知。

那如何解决这个问题呢？具体方法可以分为以下三步：

1. 在与该方法对应的持久节点的目录下，为每个进程创建一个临时顺序节点；
2. 每个进程获取所有临时节点列表，对比自己的编号是否最小，若最小，则获得锁；
3. 若本进程对应的临时节点编号不是最小的，则继续判断：
   1. 若本进程为读请求，则向比自己序号小的最后一个写请求节点注册 watch 监听，当监听到该节点释放锁后，则获取锁；
   2. 若本进程为写请求，则向比自己序号小的最后一个请求节点注册 watch 监听，当监听到该节点释放锁后，获取锁

 

5：内容总结