分布式必学的分布式锁篇（想不出好的名字了2 ＞ ＜）

欢迎访问我的blog http://www.codinglemon.cn/

立个flag，8月20日前整理出所有面试常见问题，包括有：
Java基础、JVM、多线程、Spring、Redis、MySQL、Zookeeper、Dubbo、RokectMQ、分布式锁、算法。

13. 分布式锁篇

分布式锁中推荐使用Zookeeper、Redis，MYSQL极不推荐！

在多线程环境下，由于上下文的切换，数据可能出现不一致的情况或者数据被污染，我们需要保证数据安全，所以想到了加锁。

所谓的加锁机制，就是当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问，直到该线程读取完，其他线程才可使用。

我们经常说到的秒杀场景，就是拿到库存判断，但是在分布式情况下就是会出问题的。

• 我们为了减少DB的压力，把库存预热到了KV，现在KV的库存是1。

• 服务A去Redis查询到库存发现是1，那说明我能抢到这个商品对不对，那我就准备减一了，但是还没减。

• 同时服务B也去拿发现也是1，那我也抢到了呀，那我也减。

• C同理。

等所有的服务都判断完了，你发现诶，怎么变成-2了，超卖了呀，这下完了。这就需要分布式锁的介入了。

目前分布式锁有三种实现方式（Zookeeper，Redis，MySQL）

13.1 Zookeeper

13.1.1 正常线程进程同步的机制有哪些？

• 互斥：互斥的机制，保证同一时间只有一个线程可以操作共享资源 synchronized，Lock等。

• 临界值：让多线程串行话去访问资源

• 事件通知：通过事件的通知去保证大家都有序访问共享资源

• 信号量：多个任务同时访问，同时限制数量，比如发令枪CDL，Semaphore等

13.1.2 Zookeeper如何实现分布式锁

zk节点有个唯一的特性，就是我们创建过这个节点了，你再创建zk是会报错的，那我们就利用一下他的唯一性去实现分布式锁。

1. 我们全部去创建，创建成功的第一个返回true他就可以继续下面的扣减库存操作，后续的节点访问就会全部报错，扣减失败，我们把它们丢一个队列去排队。

2. 释放锁的时候就删除该节点，再通知其他人来加锁，以此类推。

但是这样会出现死锁，第一个仔加锁成功了，在执行代码的时候，机器宕机了，那节点是不是就不能删除了？

这时创建临时节点就好了，客户端连接一断开，别的就可以监听到节点的变化了。

另外监听机制也有问题，所有服务都去监听一个节点的，节点的释放也会通知所有的服务器，如果是900个服务器呢？

这对服务器是很大的一个挑战，一个释放的消息，就好像一个牧羊犬进入了羊群，大家都四散而开，随时可能干掉机器，会占用服务资源，网络带宽等等。

这就是羊群效应（具体可以看Zookeeper篇的内容）。

此时我们可以使用临时顺序节点解决这个问题。我们就监听我们的前一个节点，因为是顺序的，很容易找到自己的前后。和之前监听一个永久节点的区别就在于，这里每个节点只监听了自己的前一个节点，释放当然也是一个个释放下去，就不会出现羊群效应了。

13.1.3 ZK在分布式锁中实践的一些缺点

Zk性能上可能并没有缓存服务那么高。

因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。

ZK中创建和删除节点只能通过Leader服务器来执行，然后将数据同步到所有的Follower机器上。

使用Zookeeper也有可能带来并发问题，只是并不常见而已。

由于网络抖动，客户端可ZK集群的session连接断了，那么zk以为客户端挂了，就会删除临时节点，这时候其他客户端就可以获取到分布式锁了。

就可能产生并发问题了，这个问题不常见是因为zk有重试机制，一旦zk集群检测不到客户端的心跳，就会重试，Curator客户端支持多种重试策略。

多次重试之后还不行的话才会删除临时节点。

13.2 Redis

基于 Redis 的单线程：由于 Redis 是单线程，所以命令会以串行的方式执行，并且本身提供了像 SETNX(set if not exists) 这样的指令，本身具有互斥性；

13.2.1 Redis如何实现分布式锁

但是，它存在一个很大的问题，当客户端 1 拿到锁后，如果发生下面的场景，就会造成死锁：

1. 程序处理业务逻辑异常，没及时释放锁
2. 进程挂了，没机会释放锁

这时，这个客户端就会一直占用这个锁，而其它客户端就永远拿不到这把锁了。

我们很容易想到的方案是，在申请锁时，给这把锁设置一个过期时间。

在 Redis 中实现时，就是给这个 key 设置一个过期时间。这里我们假设，操作共享资源的时间不会超过 10s，那么在加锁时，给这个 key 设置 10s 过期即可。这样一来，无论客户端是否异常，这个锁都可以在 10s 后被自动释放，其它客户端依旧可以拿到锁。

我们再来看分析下，它还有什么问题？

试想这样一种场景：

1. 客户端 1 加锁成功，开始操作共享资源
2. 客户端 1 操作共享资源的时间，超过了锁的过期时间，锁被自动释放
3. 客户端 2 加锁成功，开始操作共享资源
4. 客户端 1 操作共享资源完成，释放锁（但释放的是客户端 2 的锁）

看到了么，这里存在两个严重的问题：

1. 锁过期：客户端 1 操作共享资源耗时太久，导致锁被自动释放，之后被客户端 2 持有
2. 释放别人的锁：客户端 1 操作共享资源完成后，却又释放了客户端 2 的锁

第一个问题，可能是我们评估操作共享资源的时间不准确导致的。

例如，操作共享资源的时间最慢可能需要 15s，而我们却只设置了 10s 过期，那这就存在锁提前过期的风险。

第二个问题在于，一个客户端释放了其它客户端持有的锁。

想一下，导致这个问题的关键点在哪？

重点在于，每个客户端在释放锁时，都是无脑操作，并没有检查这把锁是否还归自己持有，所以就会发生释放别人锁的风险，这样的解锁流程，很不严谨！

那么锁被别人释放怎么办？

解决办法是：客户端在加锁时，设置一个只有自己知道的唯一标识进去。

例如，可以是自己的线程 ID，也可以是一个 UUID（随机且唯一），

这里释放锁使用的是 GET + DEL 两条命令，这时，又会遇到我们前面讲的原子性问题了。

1. 客户端 1 执行 GET，判断锁是自己的
2. 客户端 2 执行了 SET 命令，强制获取到锁（虽然发生概率比较低，但我们需要严谨地考虑锁的安全性模型）
3. 客户端 1 执行 DEL，却释放了客户端 2 的锁

由此可见，这两个命令还是必须要原子执行才行。

怎样原子执行呢？Lua 脚本。

我们可以把这个逻辑，写成 Lua 脚本，让 Redis 来执行。

因为 Redis 处理每一个请求是「单线程」执行的，在执行一个 Lua 脚本时，其它请求必须等待，直到这个 Lua 脚本处理完成，这样一来，GET + DEL 之间就不会插入其它命令了。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FboJpjFT-1629292110053)(http://www.codinglemon.cn/upload/2021/08/image-98bcd51de7ea49cba518cdd28dda23ad.png)]

好了，这样一路优化，整个的加锁、解锁的流程就更严谨了。

这里我们先小结一下，基于 Redis 实现的分布式锁，一个严谨的的流程如下：

1. 加锁：SET lock_key $unique_id EX $expire_time NX
2. 操作共享资源
3. 释放锁：Lua 脚本，先 GET 判断锁是否归属自己，再 DEL 释放锁

前面我们提到，锁的过期时间如果评估不好，这个锁就会有提前过期的风险。

是否可以设计这样的方案：加锁时，先设置一个过期时间，然后我们开启一个「守护线程」，定时去检测这个锁的失效时间，如果锁快要过期了，操作共享资源还未完成，那么就自动对锁进行「续期」，重新设置过期时间。

幸运的是，已经有一个库把这些工作都封装好了：Redisson

Redisson 是一个 Java 语言实现的 Redis SDK 客户端，在使用分布式锁时，它就采用了「自动续期」的方案来避免锁过期，这个守护线程我们一般也把它叫做「看门狗」线程。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-10omDFKI-1629292110055)(http://www.codinglemon.cn/upload/2021/08/image-fb24a508e9f34ac0bbc03205a3861be4.png)]

13.2.2 主从集群 + 哨兵模式下的Redis分布式锁问题

试想这样的场景：

1. 客户端 1 在主库上执行 SET 命令，加锁成功
2. 此时，主库异常宕机，SET 命令还未同步到从库上（主从复制是异步的）
3. 从库被哨兵提升为新主库，这个锁在新的主库上，丢失了！

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-IQfgcRdo-1629292110058)(http://www.codinglemon.cn/upload/2021/08/image-4c1cb6e39b6d42afbe280ac063f2504f.png)]

可见，当引入 Redis 副本后，分布锁还是可能会受到影响。

怎么解决这个问题？

为此，Redis 的作者提出一种解决方案，就是我们经常听到的 Redlock（红锁）。

Redlock 的方案基于 2 个前提：

1. 不再需要部署从库和哨兵实例，只部署主库
2. 但主库要部署多个，官方推荐至少 5 个实例

也就是说，想用使用 Redlock，你至少要部署 5 个 Redis 实例，而且都是主库，它们之间没有任何关系，都是一个个孤立的实例。

Redlock 具体如何使用呢？

整体的流程是这样的，一共分为 5 步：

1. 客户端先获取「当前时间戳T1」
2. 客户端依次向这 5 个 Redis 实例发起加锁请求（用前面讲到的 SET 命令），且每个请求会设置超时时间（毫秒级，要远小于锁的有效时间），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁
3. 如果客户端从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳T2」，如果 T2 - T1 < 锁的过期时间，此时，认为客户端加锁成功，否则认为加锁失败
4. 加锁成功，去操作共享资源（例如修改 MySQL 某一行，或发起一个 API 请求）
5. 加锁失败，向「全部节点」发起释放锁请求（前面讲到的 Lua 脚本释放锁）

那么上面这些操作会引发下面这些思考：

1) 为什么要在多个实例上加锁？

本质上是为了容错，部分实例异常宕机，剩余的实例加锁成功，整个锁服务依旧可用。

2) 为什么大多数加锁成功，才算成功？

多个 Redis 实例一起来用，其实就组成了一个「分布式系统」。

在分布式系统中，总会出现「异常节点」，所以，在谈论分布式系统问题时，需要考虑异常节点达到多少个，也依旧不会影响整个系统的「正确性」。

这是一个分布式系统「容错」问题，这个问题的结论是：如果只存在「故障」节点，只要大多数节点正常，那么整个系统依旧是可以提供正确服务的。

3) 为什么步骤 3 加锁成功后，还要计算加锁的累计耗时？

因为操作的是多个节点，所以耗时肯定会比操作单个实例耗时更久，而且，因为是网络请求，网络情况是复杂的，有可能存在延迟、丢包、超时等情况发生，网络请求越多，异常发生的概率就越大。

所以，即使大多数节点加锁成功，但如果加锁的累计耗时已经「超过」了锁的过期时间，那此时有些实例上的锁可能已经失效了，这个锁就没有意义了。

4) 为什么释放锁，要操作所有节点？

在某一个 Redis 节点加锁时，可能因为「网络原因」导致加锁失败。

例如，客户端在一个 Redis 实例上加锁成功，但在读取响应结果时，网络问题导致读取失败，那这把锁其实已经在 Redis 上加锁成功了。

所以，释放锁时，不管之前有没有加锁成功，需要释放「所有节点」的锁，以保证清理节点上「残留」的锁。

13.3 MYSQL

基于MYSQL数据库实现分布式锁主要有两种方式:

• 一种是基于数据库表实现的乐观锁和悲观锁

• 另一种是基于MYSQL自带的悲观锁,下面就来一起看一看这几种实现方式及其差异和使用场景。

13.3.1 基于数据库表

13.3.1.1 悲观锁

MYSQL实现分布式悲观锁:直接创建一张锁表，然后通过操作该表中的数据来实现。当我们要锁住某个方法或资源时，我们就在该表中增加一条记录，想要释放锁的时候就删除这条记录。

我们可以对表中某一字段做唯一性约束（比如method_name唯一），这里如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，可以执行方法体内容。

当方法执行完毕之后，想要释放锁的话，就删除该条记录。

上面这种简单的实现有以下几个问题：

1. 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

2. 这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。

3. 这把锁只能是非阻塞的，因为数据的insert操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。

4. 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了

针对上面的问题,我们可以对症下药:

1. 数据库是单点？搞两个数据库，数据之前双向同步。一旦挂掉快速切换到备库上。
2. 没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
3. 非阻塞的？搞一个while循环，直到insert成功再返回成功。
4. 非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了

但无论如何,Mysql数据库的性能和效率大家心里都有点abcd数的,在高并发的情况下, 用Mysql做分布式锁,无异于是找死…

13.3.1.2 乐观锁

大多数是基于数据版本(version)的记录机制实现的.何谓数据版本号?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表添加一个 “version”字段来实现读取出数据时,将此版本号一同读出,之后更新时,对此版本号加1.在更新过程中,会对版本号进行比较,如果是一致的,没有发生改变,则会成功执行本次操作;如果版本号不一致,则会更新失败.

具体操作就是先查询一下当前数据版本号，比如 version=4396 ，然后执行update语句时加上：

update *****,version = 4397 from xx_table where **** and version = 4396

如果能够更新说明该条信息没有被修改过，如果更新失败说明已经被修改过了，再次重试。

基于数据库表做乐观锁的一些缺点:

1. 这种操作方式，使原本一次的update操作，必须变为2次操作: select版本号一次；update一次。增加了数据库操作的次数。

2. 如果业务场景中的一次业务流程中，多个资源都需要用保证数据一致性，那么如果全部使用基于数据库资源表的乐观锁，就要让每个资源都有一张资源表，这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作，在高并发的要求下，对数据库连接的开销一定是无法忍受的。

3. 乐观锁机制往往基于系统中的数据存储逻辑，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整，如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开。

13.3.2 基于Mysql自带的悲观锁实现

利用for update加显式的行锁，这样就能利用这个行级的排他锁来实现分布式锁了，同时unlock的时候只要释放commit这个事务，就能达到释放锁的目的。

优点：实现简单

缺点：连接池爆满和事务超时的问题单点的问题，单点问题，行锁升级为表锁的问题，并发量大的时候请求量太大、没有线程唤醒机制。

连接池爆满和事务超时的问题单点的问题：利用事务进行加锁的时候，query需要占用数据库连接，在行锁的时候连接不释放，这就会导致连接池爆满。同时由于事务是有超时时间的，过了超时时间自动回滚，会导致锁的释放，这个超时时间要把控好。

适用场景:并发量略高于上面使用乐观锁的情况下,可以采用这种方法.

13.3.3 MYSQL分布式锁总结

不论如何,使用Mysql来实现分布式锁都不推荐！不推荐！不推荐！其性能,可靠性,以及实现上跟其它两种方式对比均没啥优势。

参考： 分布式锁之Zookeeper
Redis分布式锁到底安全吗？