11 张图深入理解分布式锁原理（二）

另外还应该注意的是，在我们设置锁的时候，还需要带有自身服务的业务属性，否则容易造成错乱。为什么这么说呢？举个栗子，库存服务在加完锁之后开始执行扣减库存的任务，当扣减库存完成之后，服务挂了，原先需要删除的锁资源，等到过期之后被 Redis 删除，此时库存服务 2 可以继续申请锁，如果此时库存服务 1 恢复了，它并不知道锁资源已经释放，起来后立马删除了库存服务 2 加的锁，那么此时就会出现两个问题：

1、库存服务执行完库存扣减之后，回头来进行锁资源释放的时候，发现锁实际已经不在了；

2、当库存服务 1 恢复后发现锁还在，立马删除了该锁，完成了它挂掉之前未完成的工作。但是实际上这个锁是库存服务 2 加的锁，如果此时库存服务 3 也要尝试加锁，发现可以加锁成功，和库存服务 2 一样同样对库存进行操作，那么此时就会出现线程安全问题。

经过上文的分析，这个问题的根源就是在加锁的时候没有具体区分到底是哪个服务加的锁。因此在执行命令的时候，我们需要将带有服务实例关联属性的设置为 value，这样在进行锁获取的时候检查下当前锁的持有者是谁，如果不是服务实例自己则不能执行删除操作。

那这样是不是就完美解决问题了呢？实际上还是有问题存在的，有同学会说，怎么这么多问题？实际上这种方案的实现就是在各种不完美的方案中逐渐找到相对完美的方案。

上文提到的获取锁判断是不是自己方服务实例加的锁，再执行删除锁的过程实际并不是原子的。因此还是会出现并发安全问题，这个问题可以通过 lua 脚本来解决，在 lua 脚本中实现这个逻辑，而不是在客户端中实现。

但是实际上还是有问题没有解决，比如说我们在加锁的时候会设置过期时间，但是过期时间应该设置多长时间呢？设置短了的话，出现网络超时或者服务还没有执行完业务，锁就失效了。设置长了话，其他服务节点等待获取锁的时间就会变长，降低了服务的性能。

2.2.3 基于 Redisson 实现
Redisson 实际上就是一个封装了 Redis 操作的客户端，实现了对于常见的 Redis 操作的封装。如对于 Redis 的设置锁的步骤以及删除锁的步骤都进行了封装。在设置锁的操作中，还引入了自动给锁续期的机制，SDK 检测到业务未完成，但是锁要到期后，执行定续期。这样并可以动态的调节过期时间，避免锁在业务未完成情况下被释放的问题。

同时还封装了删除锁的时候执行的业务判断后再删除的逻辑，这样我们在使用 Redisson 操作 Redis 的时候，就和我们使用 JDK 一样。

2.2.4 RedLock
为了解决 Redis 作为分布式锁存在的单点问题，Redis 的作者又提出了 Redlock 的解决方案，该解决方案依赖多个 Redis 的 Master 节点，官方推荐使用 5 个 Master 节点，他们彼此之间是独立的。大致的交互步骤如下所示：

1、首先获取当前节点的系统时间；

2、客户端尝试向所有的 Redis 实例顺序地发送加锁的请求（官方推荐 Redis 集群至少 5 个实例），在设置锁的过程中，使用相同的 key 以及随机值 value，同时请求的超时时间需要远小于锁的有效时间。这样做的目的是为了防止节点不可用的时候导致请求锁的时候被阻塞，当实例没响应的时候可以快速跳过，向下一个节点继续请求锁。

3、假设 Redis 集群规模为 5，那么如果客户端在大多数实例中（超过 3 个实例）获得了锁，同时计算了当前的时间减去步骤 1 中获得的时间，这个事件差如果小于锁的有效时间，那么此时可以认为加锁成功，可以操作执行后续的业务；

4、如果不满足步骤 3 是条件，那么就表示加锁失败，客户端需要向所有的 Redis 节点发起锁释放请求。

2.2.5 方案分析
为什么 Redlock 要在集群中多个实例上加锁呢？实际目的是通过锁的冗余来实现分布式锁的高容错性。试想一下如果只有一个 Redis 实例，一旦它挂掉了，客户端就无法进行加锁操作了或者锁信息就会丢失，影响业务功能。通过在集群中多实例中冗余锁信息，即使出现 Redis 挂了的情况，其他节点中依然存在锁信息，从而提升了分布式锁的可用性。

那么为什么还要计算几所时间呢？由于我们加锁的时候，每个节点都设置了超时时间，如果整个加锁的时间过长，整个过程的累加时间超过了锁的有效时间，那么加锁完成之后就会哦出现锁失效的情况了，因此我们需要确保加锁的事件尽可能的短，这也是为什么加锁请求都有超时时间的原因了，发现超时立马跳到下一个节点，避免单个节点耗时过长。

虽然 Redlock 看上去是比较完善的分布式解决方案，但是实际上这个方案是比较重的，需要维护一个 Redis 集群，另外过程中依赖系统时间，但是如果出现了时间跳变，那么对于整个分布式锁都有非常大的影响。

2.3 基于 Zookeeper 的分布式锁实现方案
2.3.1 实现原理
Zookeeper 是一个分布式的应用协调服务中间件，通过它也可以实现分布式锁的效果，这里介绍的是基于临时有序的 ZNode 分布式锁实现方案。在介绍方案之前，先补充下 Zookeeper 中和分布式锁息息相关的特性。

我们来看下 Zookeeper 的数据结构，实际上它是一种树形模型，类似于 Linux 的文件系统。Zookeeper 使用类似于文件目录的层级目录数据结构来组织自身的数据存储节点，这些节点就被称作为 ZNode，每个节点都用一个以斜杠（/）分隔的路径来表示，而且每个节点都有父节点（根节点除外）。另外在 Zookeeper 中，如果我们使用不同的创建参数，可以创建不同类型的 ZNode。

1、持久化 ZNode：当 createMode 为 PERSISTENT 会创建持久化 ZNode，节点存储的数据会永久保存在 Zookeeper 中，如果 createMode 为 PERSISTENT_SEQUENTIAL，则会创建有序持久化 ZNode，和之前的持久化节点不通的是，有序持久化节点的节点名称会附加上全局有序的递增序号；

2、临时 ZNode：当 createMode 为 EPHEMERAL 时，创建的节点临时节点，在与客户端的 session 过期后，对应的临时节点也会被删除。当 createMode 为 EPHEMERAL_SEQUENTIAL 时创建出来的为有序的临时节点，当 session 过期之后，节点及其存储的数据也是会被删除的。

通过上述对于节点特性的描述，可以看出来它的全局递增有序以及过期删除的特性与分布式锁实现的原理非常契合。因此通过 Zookeeper 实现分布式锁的大致可以分为以下几个步骤：

1、首先创建一个持久化节点也就是父节点，这个持久化节点代表着一个分布式锁实例；

2、当有线程想要申请分布式锁的时候，则在该持久化节点下创建临时有序节点；

3、如果此时新建的临时有序节点是该父节点小所有有序节点中序号最小的节点，那么此时就表示申请到了分布式锁；

4、如果新建的临时节点当前不是最小序号的节点，则需要不断检查是否最小，知道最终获取到锁，或者节点超时。实际上这个是通过 Zookeeper 的 watch 机制实现的，在当前节点的上一序号的节点设置监听器，检查是否为最小节点的任务可以一直阻塞，直到收到上一节点被删除的时间事件，则唤醒检查事件，检查当前节点是不是最小序号节点。

5、当线程执行完业务之后，可以手动删除该临时节点以便于释放持有的锁。另外即使服务挂掉，由于对应的 session 失效，对应的临时节点也会被删除，防止出现死锁问题。

和 Redisson 类似，我们在实际使用 Zookeeper 作为分布式锁的时候可以用 Curator 来作为开发 SDK，它同样封装了很多实现，包括可重入锁的实现，减轻了使用者的负担。

2.3.2 方案分析
看上去通过 Zookeeper 实现分布式锁还是比较好的一种解决方案，但是它是完美的吗？从上面的分布式锁的流程可知，客户端线程想要获取锁就需要创建临时节点，这个时候客户端和 Zookeeper 之间就会维护一个 session，来表示该客户端还在排队等待获取锁。因此这个方案的潜在问题就在于一旦出现网络异常，或者客户端发生 STW GC，那么就可能导致 session 关闭，从而导致临时节点被关闭，此时就会出现原来客户端持有的锁被删除了，如果有另外的客户端过来加锁的话可以成功获取，那么此时就出现并发安全问题了。因此在这种极端条件下，Zookeeper 的分布式锁实现方案也不是 100%保证安全的。

另外实际上还有基于 etcd 的分布式锁实现方案，其基本原理和 Zookeeper 差不多，感兴趣的同学可以再进行了解下。

分布式锁方案改怎么选？
通过上述几种分布式锁方案原理的阐述以及问题分析，每个方案都有自己的长处以及缺点。所以在实际项目落地的时候，我么需要结合实际来进行分布式锁方案的选择。比如如果平台中本身已经有 Redis 集群了，但是没有 Zookeeper 集群，那么我们就可以借助于现有的基础实施来落地分布式锁，不需要再去维护一套 Zookeeper 集群。

另外根据实际的业务场景，如果并发量并不是很高，也可以通过简单的数据库的分布式锁方案来实现。

总结
本文首先对从单机时代到分布式场景下的分布式锁的产生的背景进行了分析，通过对分布式锁的本质问题的探究，引出了数据库分布式锁方案、Redis 分布式锁方案以及 Zookeeper 分布式锁方案，并对每一种方案的优点以及不足进行了分析，相信大家可以在落地实现分布式锁的时候可以按照自身的情况选择合适的方案。

文章转自公众号：慕枫技术笔记