搞懂“分布式锁”，看这篇文章就对了

对于锁你们确定不会陌生，在 Java 中 synchronized 关键字和 ReentrantLock 可重入锁在咱们的代码中是常常见的，通常咱们用其在多线程环境中控制对资源的并发访问。

可是随着分布式的快速发展，本地的加锁每每不能知足咱们的须要，在咱们的分布式环境中上面加锁的方法就会失去做用。

因而人们为了在分布式环境中也能实现本地锁的效果，也是纷纷各出其招，今天让咱们来聊一聊通常分布式锁实现的套路。

为什么须要分布式锁

Martin Kleppmann 是英国剑桥大学的分布式系统的研究员，以前和 Redis 之父 Antirez 进行过关于 RedLock(红锁，后续有讲到)是否安全的激烈讨论。

Martin 认为通常咱们使用分布式锁有两个场景：

• 效率：使用分布式锁能够避免不一样节点重复相同的工做，这些工做会浪费资源。好比用户付了钱以后有可能不一样节点会发出多封短信。

• 正确性：加分布式锁一样能够避免破坏正确性的发生，若是两个节点在同一条数据上面操做，好比多个节点机器对同一个订单操做不一样的流程有可能会致使该笔订单最后状态出现错误，形成损失。

分布式锁的一些特色

当咱们肯定了在不一样节点上须要分布式锁，那么咱们须要了解分布式锁到底应该有哪些特色？

分布式锁的特色以下：

• 互斥性：和咱们本地锁同样互斥性是最基本，可是分布式锁须要保证在不一样节点的不一样线程的互斥。

• 可重入性：同一个节点上的同一个线程若是获取了锁以后那么也能够再次获取这个锁。

• 锁超时：和本地锁同样支持锁超时，防止死锁。

• 高效，高可用：加锁和解锁须要高效，同时也须要保证高可用防止分布式锁失效，能够增长降级。

• 支持阻塞和非阻塞：和 ReentrantLock 同样支持 lock 和 trylock 以及 tryLock(long timeOut)。

• 支持公平锁和非公平锁(可选)：公平锁的意思是按照请求加锁的顺序得到锁，非公平锁就相反是无序的。这个通常来讲实现的比较少。

常见的分布式锁

咱们了解了一些特色以后，咱们通常实现分布式锁有如下几个方式：

• MySQL

• ZK

• Redis

• 自研分布式锁：如谷歌的 Chubby。

下面分开介绍一下这些分布式锁的实现原理。

MySQL

首先来讲一下 MySQL 分布式锁的实现原理，相对来讲这个比较容易理解，毕竟数据库和咱们开发人员在平时的开发中息息相关。

对于分布式锁咱们能够建立一个锁表：

前面咱们所说的 lock()，trylock(long timeout)，trylock() 这几个方法能够用下面的伪代码实现。

lock()

lock 通常是阻塞式的获取锁，意思就是不获取到锁誓不罢休，那么咱们能够写一个死循环来执行其操做：

mysqlLock.lcok 内部是一个 sql，为了达到可重入锁的效果，咱们应该先进行查询，若是有值，须要比较 node_info 是否一致。

这里的 node_info 能够用机器 IP 和线程名字来表示，若是一致就加可重入锁 count 的值，若是不一致就返回 false。若是没有值就直接插入一条数据。

伪代码以下：

须要注意的是这一段代码须要加事务，必需要保证这一系列操做的原子性。

tryLock() 和 tryLock(long timeout)

tryLock() 是非阻塞获取锁，若是获取不到就会立刻返回，代码以下：

tryLock(long timeout) 实现以下：

mysqlLock.lock 和上面同样，可是要注意的是 select … for update 这个是阻塞的获取行锁，若是同一个资源并发量较大仍是有可能会退化成阻塞的获取锁。

unlock()

unlock 的话若是这里的 count 为 1 那么能够删除，若是大于 1 那么须要减去 1。

锁超时

咱们有可能会遇到咱们的机器节点挂了，那么这个锁就不会获得释放，咱们能够启动一个定时任务，经过计算通常咱们处理任务的时间。

好比是 5ms，那么咱们能够稍微扩大一点，当这个锁超过 20ms 没有被释放咱们就能够认定是节点挂了而后将其直接释放。

MySQL 小结：

• 适用场景：MySQL 分布式锁通常适用于资源不存在数据库，若是数据库存在好比订单，能够直接对这条数据加行锁，不须要咱们上面多的繁琐的步骤。

  好比一个订单，咱们能够用 select * from order_table where id = 'xxx' for update 进行加行锁，那么其余的事务就不能对其进行修改。

• 优势：理解起来简单，不须要维护额外的第三方中间件(好比 Redis，ZK)。

• 缺点：虽然容易理解可是实现起来较为繁琐，须要本身考虑锁超时，加事务等等。性能局限于数据库，通常对比缓存来讲性能较低。对于高并发的场景并非很适合。

乐观锁

前面咱们介绍的都是悲观锁，这里想额外提一下乐观锁，在咱们实际项目中也是常常实现乐观锁，由于咱们加行锁的性能消耗比较大，一般咱们对于一些竞争不是那么激烈。

可是其又须要保证咱们并发的顺序执行使用乐观锁进行处理，咱们能够对咱们的表加一个版本号字段。

那么咱们查询出来一个版本号以后，update 或者 delete 的时候须要依赖咱们查询出来的版本号，判断当前数据库和查询出来的版本号是否相等，若是相等那么就能够执行，若是不等那么就不能执行。

这样的一个策略很像咱们的 CAS(Compare And Swap)，比较并交换是一个原子操做。这样咱们就能避免加 select * for update 行锁的开销。

ZooKeeper

ZooKeeper 也是咱们常见的实现分布式锁方法，相比于数据库若是没了解过 ZooKeeper 可能上手比较难一些。

ZooKeeper 是以 Paxos 算法为基础的分布式应用程序协调服务。ZK 的数据节点和文件目录相似，因此咱们能够用此特性实现分布式锁。

咱们以某个资源为目录，而后这个目录下面的节点就是咱们须要获取锁的客户端，未获取到锁的客户端注册须要注册 Watcher 到上一个客户端，能够用下图表示：

/lock 是咱们用于加锁的目录，/resource_name 是咱们锁定的资源，其下面的节点按照咱们加锁的顺序排列。

Curator

Curator 封装了 ZooKeeper 底层的 API，使咱们更加容易方便的对 ZooKeeper 进行操做，而且它封装了分布式锁的功能，这样咱们就不须要在本身实现了。

Curator 实现了可重入锁(InterProcessMutex)，也实现了不可重入锁(InterProcessSemaphoreMutex)。在可重入锁中还实现了读写锁。

InterProcessMutex

InterProcessMutex 是 Curator 实现的可重入锁，咱们能够经过下面的一段代码实现咱们的可重入锁：

咱们利用 acuire 进行加锁，release 进行解锁。

加锁的流程具体以下：

• 首先进行可重入的断定：这里的可重入锁记录在 ConcurrentMap<Thread, LockData>threadData 这个 Map 里面。

  若是 threadData.get(currentThread)是有值的那么就证实是可重入锁，而后记录就会加 1。

  咱们以前的 MySQL 其实也能够经过这种方法去优化，能够不须要 count 字段的值，将这个维护在本地能够提升性能。

• 而后在咱们的资源目录下建立一个节点：好比这里建立一个 /0000000002 这个节点，这个节点须要设置为 EPHEMERAL_SEQUENTIAL 也就是临时节点而且有序。

• 获取当前目录下全部子节点，判断本身的节点是否位于子节点第一个。

• 若是是第一个，则获取到锁，那么能够返回。

• 若是不是第一个，则证实前面已经有人获取到锁了，那么须要获取本身节点的前一个节点。

  /0000000002 的前一个节点是 /0000000001，咱们获取到这个节点以后，再上面注册 Watcher(这里的 Watcher 其实调用的是 object.notifyAll()，用来解除阻塞)。

• object.wait(timeout) 或 object.wait()：进行阻塞等待，这里和咱们第 5 步的 Watcher 相对应。

解锁的具体流程：

• 首先进行可重入锁的断定：若是有可重入锁只须要次数减 1 便可，减 1 以后加锁次数为 0 的话继续下面步骤，不为 0 直接返回。

• 删除当前节点。

• 删除 threadDataMap 里面的可重入锁的数据。

读写锁

Curator 提供了读写锁，其实现类是 InterProcessReadWriteLock，这里的每一个节点都会加上前缀：

private static final String READ_LOCK_NAME  = "__READ__";
private static final String WRITE_LOCK_NAME = "__WRIT__";
复制代码

根据不一样的前缀区分是读锁仍是写锁，对于读锁，若是发现前面有写锁，那么须要将 Watcher 注册到和本身最近的写锁。写锁的逻辑和咱们以前 4.2 分析的依然保持不变。

锁超时

ZooKeeper 不须要配置锁超时，因为咱们设置节点是临时节点，咱们的每一个机器维护着一个 ZK 的 Session，经过这个 Session，ZK 能够判断机器是否宕机。

若是咱们的机器挂掉的话，那么这个临时节点对应的就会被删除，因此咱们不须要关心锁超时。

ZK 小结：

• 优势：ZK 能够不须要关心锁超时时间，实现起来有现成的第三方包，比较方便，而且支持读写锁，ZK 获取锁会按照加锁的顺序，因此其是公平锁。对于高可用利用 ZK 集群进行保证。

• 缺点：ZK 须要额外维护，增长维护成本，性能和 MySQL 相差不大，依然比较差。而且须要开发人员了解 ZK 是什么。

Redis

你们在网上搜索分布式锁，恐怕最多的实现就是 Redis 了，Redis 由于其性能好，实现起来简单因此让不少人都对其十分青睐。

Redis 分布式锁简单实现

熟悉 Redis 的同窗那么确定对 setNx(set if not exist) 方法不陌生，若是不存在则更新，其能够很好的用来实现咱们的分布式锁。

对于某个资源加锁咱们只须要：

setNx resourceName value
复制代码

这里有个问题，加锁了以后若是机器宕机那么这个锁就不会获得释放因此会加入过时时间，加入过时时间须要和 setNx 同一个原子操做。

在 Redis 2.8 以前咱们须要使用 Lua 脚本达到咱们的目的，可是 Redis 2.8 以后 Redis 支持 nx 和 ex 操做是同一原子操做。

set resourceName value ex 5 nx
复制代码

Redission

Javaer 都知道 Jedis，Jedis 是 Redis 的 Java 实现的客户端，其 API 提供了比较全面的 Redis 命令的支持。

Redission 也是 Redis 的客户端，相比于 Jedis 功能简单。Jedis 简单使用阻塞的 I/O 和 Redis 交互，Redission 经过 Netty 支持非阻塞 I/O。

Jedis 最新版本 2.9.0 是 2016 年的快 3 年了没有更新，而 Redission 最新版本是 2018 年 10 月更新。

Redission 封装了锁的实现，其继承了 java.util.concurrent.locks.Lock 的接口，让咱们像操做咱们的本地 Lock 同样去操做 Redission 的 Lock。

下面介绍一下其如何实现分布式锁：

Redission 不只提供了 Java 自带的一些方法(lock，tryLock)，还提供了异步加锁，对于异步编程更加方便。

因为内部源码较多，就不贴源码了，这里用文字叙述来分析它是如何加锁的，这里分析一下 tryLock 方法：

①尝试加锁：首先会尝试进行加锁，因为须要兼容老版本的 Redis，因此不能直接使用 ex，nx 原子操做的 API，那么就只能使用 Lua 脚本，相关的 Lua 脚本以下：

能够看见它并无使用咱们的 sexNx 来进行操做，而是使用的 hash 结构，咱们的每个须要锁定的资源均可以看作是一个 HashMap，锁定资源的节点信息是 Key，锁定次数是 Value。

经过这种方式能够很好的实现可重入的效果，只须要对 Value 进行加 1 操做，就能进行可重入锁。固然这里也能够用以前咱们说的本地计数进行优化。

②若是尝试加锁失败，判断是否超时，若是超时则返回 false。

③若是加锁失败以后，没有超时，那么须要在名字为 redisson_lock__channel+lockName 的 channel 上进行订阅，用于订阅解锁消息，而后一直阻塞直到超时，或者有解锁消息。

④重试步骤 1，2，3，直到最后获取到锁，或者某一步获取锁超时。

对于咱们的 unlock 方法比较简单也是经过 lua 脚本进行解锁，若是是可重入锁，只是减 1。若是是非加锁线程解锁，那么解锁失败。

Redission 还有公平锁的实现，对于公平锁其利用了 list 结构和 hashset 结构分别用来保存咱们排队的节点，和咱们节点的过时时间，用这两个数据结构帮助咱们实现公平锁，这里就不展开介绍了，有兴趣能够参考源码。

RedLock

咱们想象一个这样的场景当机器 A 申请到一把锁以后，若是 Redis 主宕机了，这个时候从机并无同步到这一把锁，那么机器 B 再次申请的时候就会再次申请到这把锁。

为了解决这个问题 Redis 做者提出了 RedLock 红锁的算法，在 Redission 中也对 RedLock 进行了实现。

经过上面的代码，咱们须要实现多个 Redis 集群，而后进行红锁的加锁，解锁。

具体的步骤以下：

①首先生成多个 Redis 集群的 Rlock，并将其构形成 RedLock。

②依次循环对三个集群进行加锁，加锁的过程和 5.2 里面一致。

③若是循环加锁的过程当中加锁失败，那么须要判断加锁失败的次数是否超出了最大值，这里的最大值是根据集群的个数，好比三个那么只容许失败一个，五个的话只容许失败两个，要保证多数成功。

④加锁的过程当中须要判断是否加锁超时，有可能咱们设置加锁只能用 3ms，第一个集群加锁已经消耗了 3ms 了。那么也算加锁失败。

⑤3，4 步里面加锁失败的话，那么就会进行解锁操做，解锁会对全部的集群在请求一次解锁。

能够看见 RedLock 基本原理是利用多个 Redis 集群，用多数的集群加锁成功，减小 Redis 某个集群出故障，形成分布式锁出现问题的几率。

Redis 小结：

• 优势：对于 Redis 实现简单，性能对比 ZK 和 MySQL 较好。若是不须要特别复杂的要求，本身就能够利用 setNx 进行实现，若是本身须要复杂的需求的话，能够利用或者借鉴 Redission。对于一些要求比较严格的场景可使用 RedLock。

• 缺点：须要维护 Redis 集群，若是要实现 RedLock 须要维护更多的集群。

• 工做一到五年的java 开发工程师朋友能够加入咱们Java架构交流群：760940986 群内提供 高可用，高并发，spring源码，mybatis源码，JVM，大数据，Netty等多个技术知识的架构视频资料 还有大把大牛在群内交流以及解答面试指导，问题答疑~~要进来和大牛交流学习提高提高本身吗~~~~
  

分布式锁的安全问题

上面咱们介绍过红锁，可是 Martin Kleppmann 认为其依然不安全。

有关于 Martin 反驳的几点，我认为其实不只仅局限于 RedLock，前面说的算法基本都有这个问题，下面咱们来讨论一下这些问题。

长时间的 GC pause

熟悉 Java 的同窗确定对 GC 不陌生，在 GC 的时候会发生 STW(stop-the-world)。

例如 CMS 垃圾回收器，它会有两个阶段进行 STW 防止引用继续进行变化。那么有可能会出现下面图(引用至 Martin 反驳 Redlock 的文章)中这个状况：

client1 获取了锁而且设置了锁的超时时间，可是 client1 以后出现了 STW，这个 STW 时间比较长，致使分布式锁进行了释放。

client2 获取到了锁，这个时候 client1 恢复了锁，那么就会出现 client1，2 同时获取到锁，这个时候分布式锁不安全问题就出现了。

这个不只仅局限于 RedLock，对于咱们的 ZK，MySQL 同样的有一样的问题。

时钟发生跳跃

对于 Redis 服务器若是其时间发生了跳跃，确定会影响咱们锁的过时时间。

那么咱们的锁过时时间就不是咱们预期的了，也会出现 client1 和 client2 获取到同一把锁，也会出现不安全，这个对于 MySQL 也会出现。可是 ZK 因为没有设置过时时间，那么发生跳跃也不会受影响。

长时间的网络 I/O

这个问题和咱们的 GC 的 STW 很像，也就是咱们这个获取了锁以后咱们进行网络调用，其调用时间由可能比咱们锁的过时时间都还长，那么也会出现不安全的问题，这个 MySQL 也会有，ZK 也不会出现这个问题。

对于这三个问题，在网上包括 Redis 做者在内发起了不少讨论。

GC 的 STW

对于这个问题能够看见基本全部的都会出现问题，Martin 给出了一个解法，对于 ZK 这种他会生成一个自增的序列，那么咱们真正进行对资源操做的时候，须要判断当前序列是不是最新，有点相似于乐观锁。

固然这个解法 Redis 做者进行了反驳，你既然都能生成一个自增的序列了那么你彻底不须要加锁了，也就是能够按照相似于 MySQL 乐观锁的解法去作。

我本身认为这种解法增长了复杂性，当咱们对资源操做的时候须要增长判断序列号是不是最新，不管用什么判断方法都会增长复杂度，后面会介绍谷歌的 Chubby 提出了一个更好的方案。

时钟发生跳跃

Martin 以为 RedLock 不安全很大的缘由也是由于时钟的跳跃，由于锁过时强依赖于时间，可是 ZK 不须要依赖时间，依赖每一个节点的 Session。

Redis 做者也给出了解答，对于时间跳跃分为人为调整和 NTP 自动调整：

• 人为调整：人为调整影响的彻底能够人为不调整，这个是处于可控的。

• NTP 自动调整：这个能够经过必定的优化，把跳跃时间控制在可控范围内，虽然会跳跃，可是是彻底能够接受的。

长时间的网络 I/O

这一块不是他们讨论的重点，我本身以为，对于这个问题的优化能够控制网络调用的超时时间，把全部网络调用的超时时间相加。

那么咱们锁过时时间其实应该大于这个时间，固然也能够经过优化网络调用好比串行改为并行，异步化等。

Chubby 的一些优化

你们搜索 ZK 的时候，会发现他们都写了 ZK 是 Chubby 的开源实现，Chubby 内部工做原理和 ZK 相似。可是 Chubby 的定位是分布式锁和 ZK 有点不一样。

Chubby 也是使用上面自增序列的方案用来解决分布式不安全的问题，可是它提供了多种校验方法：

• CheckSequencer()：调用 Chubby 的 API 检查此时这个序列号是否有效。

• 访问资源服务器检查，判断当前资源服务器最新的序列号和咱们的序列号的大小。

• lock-delay：为了防止咱们校验的逻辑入侵咱们的资源服务器，其提供了一种方法当客户端失联的时候，并不会当即释放锁，而是在必定的时间内(默认 1min)阻止其余客户端拿去这个锁。

  那么也就是给予了必定的 buffer 等待 STW 恢复，而咱们的 GC 的 STW 时间若是比 1min 还长那么你应该检查你的程序，而不是怀疑你的分布式锁了。

小结

本文主要讲了多种分布式锁的实现方法，以及它们的一些优缺点。最后也说了一下关于分布式锁的安全的问题。

对于不一样的业务须要的安全程度彻底不一样，咱们须要根据本身的业务场景，经过不一样的维度分析，选取最适合本身的方案。

本文来源于微信公众号“咖啡拿铁”