再有人问你分布式锁是什么,就把这篇文章发给他

现在面试,一般都会聊聊分布式系统这块的东西。通常面试官都会从服务框架(Spring Cloud、Dubbo)聊起,一路聊到分布式事务、分布式锁、ZooKeeper 等知识。

所以咱们就来聊聊分布式锁这块的知识,先具体的来看看 Redis 分布式锁的实现原理。

说实话,如果在公司里落地生产环境用分布式锁的时候,一定是会用开源类库的,比如 Redis 分布式锁,一般就是用 Redisson 框架就好了,非常的简便易用。

大家如果有兴趣,可以去 Redisson 的官网,看看如何在项目中引入 Redisson 的依赖,然后基于 Redis 实现分布式锁的加锁与释放锁。

下面给大家看一段简单的使用代码片段,先直观的感受一下:

怎么样,上面那段代码,是不是感觉简单的不行!此外,人家还支持 Redis 单实例、Redis 哨兵、Redis Cluster、redis master-slave 等各种部署架构,都可以给你完美实现。

Redisson 实现 Redis 分布式锁的底层原理

好的,接下来就通过一张手绘图,给大家说说 Redisson 这个开源框架对 Redis 分布式锁的实现原理。

加锁机制

咱们来看上面那张图,现在某个客户端要加锁。如果该客户端面对的是一个 Redis Cluster 集群,他首先会根据 Hash 节点选择一台机器。

这里注意,仅仅只是选择一台机器!这点很关键!紧接着,就会发送一段 Lua 脚本到 Redis 上,那段 Lua 脚本如下所示:

为啥要用 Lua 脚本呢?因为一大坨复杂的业务逻辑,可以通过封装在 Lua 脚本中发送给 Redis,保证这段复杂业务逻辑执行的原子性。

那么,这段 Lua 脚本是什么意思呢?这里 KEYS[1] 代表的是你加锁的那个 Key,比如说:RLock lock = redisson.getLock("myLock");这里你自己设置了加锁的那个锁 Key 就是“myLock”。

ARGV[1] 代表的就是锁 Key 的默认生存时间,默认 30 秒。ARGV[2] 代表的是加锁的客户端的 ID,类似于下面这样:8743c9c0-0795-4907-87fd-6c719a6b4586:1。

给大家解释一下,第一段 if 判断语句,就是用“exists myLock”命令判断一下,如果你要加锁的那个锁 Key 不存在的话,你就进行加锁。如何加锁呢?很简单,用下面的命令:hset myLock。

8743c9c0-0795-4907-87fd-6c719a6b4586:1 1,通过这个命令设置一个 Hash 数据结构,这行命令执行后,会出现一个类似下面的数据结构:

上述就代表“8743c9c0-0795-4907-87fd-6c719a6b4586:1”这个客户端对“myLock”这个锁 Key 完成了加锁。

接着会执行“pexpire myLock 30000”命令,设置 myLock 这个锁 Key 的生存时间是 30 秒。好了,到此为止,加锁完成了。

锁互斥机制

那么在这个时候,如果客户端 2 来尝试加锁,执行了同样的一段 Lua 脚本,会咋样呢?

很简单,第一个 if 判断会执行“exists myLock”,发现 myLock 这个锁 Key 已经存在了。

接着第二个 if 判断,判断一下,myLock 锁 Key 的 Hash 数据结构中,是否包含客户端 2 的 ID,但是明显不是的,因为那里包含的是客户端 1 的 ID。

所以,客户端 2 会获取到 pttl myLock 返回的一个数字,这个数字代表了 myLock 这个锁 Key 的剩余生存时间。

比如还剩 15000 毫秒的生存时间。此时客户端 2 会进入一个 while 循环,不停的尝试加锁。

watch dog 自动延期机制

客户端 1 加锁的锁 Key 默认生存时间才 30 秒,如果超过了 30 秒,客户端 1 还想一直持有这把锁,怎么办呢?

简单!只要客户端 1 一旦加锁成功,就会启动一个 watch dog 看门狗,他是一个后台线程,会每隔 10 秒检查一下,如果客户端 1 还持有锁 Key,那么就会不断的延长锁 Key 的生存时间。

可重入加锁机制

那如果客户端 1 都已经持有了这把锁了,结果可重入的加锁会怎么样呢?比如下面这种代码:

这时我们来分析一下上面那段 Lua 脚本。第一个if判断肯定不成立,“exists myLock”会显示锁 Key 已经存在了。

第二个 if 判断会成立,因为 myLock 的 Hash 数据结构中包含的那个 ID,就是客户端 1 的那个 ID,也就是“8743c9c0-0795-4907-87fd-6c719a6b4586:1”。

此时就会执行可重入加锁的逻辑,他会用:incrby myLock 8743c9c0-0795-4907-87fd-6c71a6b4586:1 1,通过这个命令,对客户端 1 的加锁次数,累加 1。

此时 myLock 数据结构变为下面这样:

大家看到了吧,那个 myLock 的 Hash 数据结构中的那个客户端 ID,就对应着加锁的次数。

释放锁机制

如果执行 lock.unlock(),就可以释放分布式锁,此时的业务逻辑也是非常简单的。其实说白了,就是每次都对 myLock 数据结构中的那个加锁次数减 1。

如果发现加锁次数是 0 了,说明这个客户端已经不再持有锁了,此时就会用:“del myLock”命令,从 Redis 里删除这个 Key。

然后呢,另外的客户端 2 就可以尝试完成加锁了。这就是所谓的分布式锁的开源 Redisson 框架的实现机制。

一般我们在生产系统中,可以用 Redisson 框架提供的这个类库来基于 Redis 进行分布式锁的加锁与释放锁。

上述 Redis 分布式锁的缺点

上面那种方案最大的问题,就是如果你对某个 Redis Master 实例,写入了 myLock 这种锁 Key 的 Value,此时会异步复制给对应的 Master Slave 实例。

但是这个过程中一旦发生 Redis Master 宕机,主备切换,Redis Slave 变为了 Redis Master。

接着就会导致,客户端 2 来尝试加锁的时候,在新的 Redis Master 上完成了加锁,而客户端 1 也以为自己成功加了锁。

此时就会导致多个客户端对一个分布式锁完成了加锁。这时系统在业务语义上一定会出现问题,导致各种脏数据的产生。

所以这个就是 Redis Cluster,或者是 redis master-slave 架构的主从异步复制导致的 Redis 分布式锁的最大缺陷:在 Redis Master 实例宕机的时候,可能导致多个客户端同时完成加锁。

七张图彻底讲清楚 ZooKeeper 分布式锁的实现原理

下面再给大家聊一下 ZooKeeper 实现分布式锁的原理。同理,我是直接基于比较常用的 Curator 这个开源框架,聊一下这个框架对 ZooKeeper(以下简称 ZK)分布式锁的实现。

一般除了大公司是自行封装分布式锁框架之外,建议大家用这些开源框架封装好的分布式锁实现,这是一个比较快捷省事儿的方式。

ZooKeeper 分布式锁机制

接下来我们一起来看看,多客户端获取及释放 ZK 分布式锁的整个流程及背后的原理。

首先大家看看下面的图,如果现在有两个客户端一起要争抢 ZK 上的一把分布式锁,会是个什么场景?

如果大家对 ZK 还不太了解的话,建议先自行百度一下,简单了解点基本概念,比如 ZK 有哪些节点类型等等。

参见上图。ZK 里有一把锁,这个锁就是 ZK 上的一个节点。然后呢,两个客户端都要来获取这个锁,具体是怎么来获取呢?

咱们就假设客户端 A 抢先一步,对 ZK 发起了加分布式锁的请求,这个加锁请求是用到了 ZK 中的一个特殊的概念,叫做“临时顺序节点”。

简单来说,就是直接在"my_lock"这个锁节点下,创建一个顺序节点,这个顺序节点有 ZK 内部自行维护的一个节点序号。

比如说,第一个客户端来搞一个顺序节点,ZK 内部会给起个名字叫做:xxx-000001。

然后第二个客户端来搞一个顺序节点,ZK 可能会起个名字叫做:xxx-000002。

大家注意一下,最后一个数字都是依次递增的,从 1 开始逐次递增。ZK 会维护这个顺序。

所以这个时候,假如说客户端 A 先发起请求,就会搞出来一个顺序节点,大家看下面的图,Curator 框架大概会弄成如下的样子:

大家看,客户端 A 发起一个加锁请求,先会在你要加锁的 node 下搞一个临时顺序节点,这一大坨长长的名字都是 Curator 框架自己生成出来的。

然后,那个最后一个数字是"1"。大家注意一下,因为客户端 A 是第一个发起请求的,所以给他搞出来的顺序节点的序号是"1"。

接着客户端 A 创建完一个顺序节点。还没完,他会查一下"my_lock"这个锁节点下的所有子节点,并且这些子节点是按照序号排序的,这个时候他大概会拿到这么一个集合:

接着客户端 A 会走一个关键性的判断,就是说:唉!兄弟,这个集合里,我创建的那个顺序节点,是不是排在第一个啊?

如果是的话,那我就可以加锁了啊!因为明明我就是第一个来创建顺序节点的人,所以我就是第一个尝试加分布式锁的人啊!

Bingo!加锁成功!大家看下面的图,再来直观的感受一下整个过程:

接着假如说,客户端 A 都加完锁了,客户端 B 过来想要加锁了,这个时候他会干一样的事儿:先是在"my_lock"这个锁节点下创建一个临时顺序节点,此时名字会变成类似于:

大家看看下面的图:

客户端 B 因为是第二个来创建顺序节点的,所以 ZK 内部会维护序号为"2"。

接着客户端 B 会走加锁判断逻辑,查询"my_lock"锁节点下的所有子节点,按序号顺序排列,此时他看到的类似于:

同时检查自己创建的顺序节点,是不是集合中的第一个?明显不是啊,此时第一个是客户端 A 创建的那个顺序节点,序号为"01"的那个。所以加锁失败!

加锁失败了以后,客户端 B 就会通过 ZK 的 API 对他的顺序节点的上一个顺序节点加一个监听器。ZK 天然就可以实现对某个节点的监听。

如果大家还不知道 ZK 的基本用法,可以百度查阅,非常的简单。客户端 B 的顺序节点是:

他的上一个顺序节点,不就是下面这个吗?

即客户端 A 创建的那个顺序节点!所以,客户端 B 会对

这个节点加一个监听器,监听这个节点是否被删除等变化!大家看下面的图:

接着,客户端 A 加锁之后,可能处理了一些代码逻辑,然后就会释放锁。那么,释放锁是个什么过程呢?

其实很简单,就是把自己在 ZK 里创建的那个顺序节点,也就是:

这个节点给删除。删除了那个节点之后,ZK 会负责通知监听这个节点的监听器,也就是客户端 B 之前加的那个监听器,说:兄弟,你监听的那个节点被删除了,有人释放了锁。

此时客户端 B 的监听器感知到了上一个顺序节点被删除,也就是排在他之前的某个客户端释放了锁。

此时,就会通知客户端 B 重新尝试去获取锁,也就是获取"my_lock"节点下的子节点集合,此时为:

集合里此时只有客户端 B 创建的唯一的一个顺序节点了!然后呢,客户端 B 判断自己居然是集合中的第一个顺序节点,Bingo!可以加锁了!直接完成加锁,运行后续的业务代码即可,运行完了之后再次释放锁。

其实如果有客户端 C、客户端 D 等 N 个客户端争抢一个 ZK 分布式锁,原理都是类似的:

  • 大家都是上来直接创建一个锁节点下的一个接一个的临时顺序节点。
  • 如果自己不是第一个节点,就对自己上一个节点加监听器。
  • 只要上一个节点释放锁,自己就排到前面去了,相当于是一个排队机制。

而且用临时顺序节点的另外一个用意就是,如果某个客户端创建临时顺序节点之后,不小心自己宕机了也没关系,ZK 感知到那个客户端宕机,会自动删除对应的临时顺序节点,相当于自动释放锁,或者是自动取消自己的排队。

最后,咱们来看下用 Curator 框架进行加锁和释放锁的一个过程:

其实用开源框架就是这点好,方便。这个 Curator 框架的 ZK 分布式锁的加锁和释放锁的实现原理,就是上面我们说的那样子。

但是如果你要手动实现一套那个代码的话。还是有点麻烦的,要考虑到各种细节,异常处理等等。所以大家如果考虑用 ZK 分布式锁,可以参考下本文的思路。

每秒上千订单场景下的分布式锁高并发优化实践

接着就给大家聊一个有意思的话题:每秒上千订单场景下,如何对分布式锁的并发能力进行优化?

首先,我们一起来看看这个问题的背景?前段时间有个朋友在外面面试,然后有一天找我聊说:有一个国内不错的电商公司,面试官给他出了一个场景题:

假如下单时,用分布式锁来防止库存超卖,但是是每秒上千订单的高并发场景,如何对分布式锁进行高并发优化来应对这个场景?

他说他当时没答上来,因为没做过没什么思路。其实我当时听到这个面试题心里也觉得有点意思,因为如果是我来面试候选人的话,应该会给的范围更大一些。

比如,让面试的同学聊一聊电商高并发秒杀场景下的库存超卖解决方案,各种方案的优缺点以及实践,进而聊到分布式锁这个话题。

因为库存超卖问题是有很多种技术解决方案的,比如悲观锁,分布式锁,乐观锁,队列串行化,Redis 原子操作,等等吧。

但是既然那个面试官兄弟限定死了用分布式锁来解决库存超卖,我估计就是想问一个点:在高并发场景下如何优化分布式锁的并发性能。

我觉得,面试官提问的角度还是可以接受的,因为在实际落地生产的时候,分布式锁这个东西保证了数据的准确性,但是他天然并发能力有点弱。

刚好我之前在自己项目的其他场景下,确实是做过高并发场景下的分布式锁优化方案,因此正好是借着这个朋友的面试题,把分布式锁的高并发优化思路,给大家来聊一聊。

库存超卖现象是怎么产生的?

先来看看如果不用分布式锁,所谓的电商库存超卖是啥意思?大家看看下面的图:

这个图,其实很清晰了,假设订单系统部署在两台机器上,不同的用户都要同时买 10 台 iPhone,分别发了一个请求给订单系统。

接着每个订单系统实例都去数据库里查了一下,当前 iPhone 库存是 12 台。俩大兄弟一看,乐了,12 台库存大于了要买的 10 台数量啊!

于是乎,每个订单系统实例都发送 SQL 到数据库里下单,然后扣减了 10 个库存,其中一个将库存从 12 台扣减为 2 台,另外一个将库存从 2 台扣减为 -8 台。

现在完了,库存出现了负数!泪奔啊,没有 20 台 iPhone 发给两个用户啊!这可如何是好。

用分布式锁如何解决库存超卖问题?

我们用分布式锁如何解决库存超卖问题呢?其实很简单,回忆一下上次我们说的那个分布式锁的实现原理:

同一个锁 Key,同一时间只能有一个客户端拿到锁,其他客户端会陷入无限的等待来尝试获取那个锁,只有获取到锁的客户端才能执行下面的业务逻辑。

代码大概就是上面那个样子,现在我们来分析一下,为啥这样做可以避免库存超卖?

大家可以顺着上面的那个步骤序号看一遍,马上就明白了。

从上图可以看到,只有一个订单系统实例可以成功加分布式锁,然后只有他一个实例可以查库存、判断库存是否充足、下单扣减库存,接着释放锁。

释放锁之后,另外一个订单系统实例才能加锁,接着查库存,一下发现库存只有 2 台了,库存不足,无法购买,下单失败。不会将库存扣减为 -8 的。

有没其他方案解决库存超卖问题?

当然有啊!比如悲观锁,分布式锁,乐观锁,队列串行化,异步队列分散,Redis 原子操作,等等,很多方案,我们对库存超卖有自己的一整套优化机制。

但是前面说过了,这篇文章就聊一个分布式锁的并发优化,不是聊库存超卖的解决方案,所以库存超卖只是一个业务场景而已。

分布式锁的方案在高并发场景下

好,现在我们来看看,分布式锁的方案在高并发场景下有什么问题?

问题很大啊!兄弟,不知道你看出来了没有。分布式锁一旦加了之后,对同一个商品的下单请求,会导致所有客户端都必须对同一个商品的库存锁 Key 进行加锁。

比如,对 iPhone 这个商品的下单,都必对“iphone_stock”这个锁 Key 来加锁。这样会导致对同一个商品的下单请求,就必须串行化,一个接一个的处理。

大家再回去对照上面的图反复看一下,应该能想明白这个问题。

假设加锁之后,释放锁之前,查库存→创建订单→扣减库存,这个过程性能很高吧,算他全过程 20 毫秒,这应该不错了。

那么 1 秒是 1000 毫秒,只能容纳 50 个对这个商品的请求依次串行完成处理。

比如一秒钟来 50 个请求,都是对 iPhone 下单的,那么每个请求处理 20 毫秒,一个一个来,最后 1000 毫秒正好处理完 50 个请求。

大家看一眼下面的图,加深一下感觉。

所以看到这里,大家起码也明白了,简单的使用分布式锁来处理库存超卖问题,存在什么缺陷。

缺陷就是同一个商品多用户同时下单的时候,会基于分布式锁串行化处理,导致没法同时处理同一个商品的大量下单的请求。

这种方案,要是应对那种低并发、无秒杀场景的普通小电商系统,可能还可以接受。

因为如果并发量很低,每秒就不到 10 个请求,没有瞬时高并发秒杀单个商品的场景的话,其实也很少会对同一个商品在 1 秒内瞬间下 1000 个订单,因为小电商系统没那场景。

如何对分布式锁进行高并发优化?

好了,终于引入正题了,那么现在怎么办呢?

面试官说,我现在就卡死,库存超卖就是用分布式锁来解决,而且一秒对一个 iPhone 下上千订单,怎么优化?

现在按照刚才的计算,你 1 秒钟只能处理针对 iPhone 的 50 个订单。其实说出来也很简单,相信很多人看过 Java 里的 ConcurrentHashMap 的源码和底层原理,应该知道里面的核心思路,就是分段加锁!

把数据分成很多个段,每个段是一个单独的锁,所以多个线程过来并发修改数据的时候,可以并发的修改不同段的数据。不至于说,同一时间只能有一个线程独占修改 ConcurrentHashMap 中的数据。

另外,Java 8 中新增了一个 LongAdder 类,也是针对 Java 7 以前的 AtomicLong 进行的优化,解决的是 CAS 类操作在高并发场景下,使用乐观锁思路,会导致大量线程长时间重复循环。

LongAdder 中也是采用了类似的分段 CAS 操作,失败则自动迁移到下一个分段进行 CAS 的思路。

其实分布式锁的优化思路也是类似的,之前我们是在另外一个业务场景下落地了这个方案到生产中,不是在库存超卖问题里用的。

但是库存超卖这个业务场景不错,很容易理解,所以我们就用这个场景来说一下。

大家看看下面的图:

这就是分段加锁。假如你现在 iPhone 有 1000 个库存,那么你完全可以给拆成 20 个库存段。

要是你愿意,可以在数据库的表里建 20 个库存字段,比如 stock_01,stock_02,类似这样的,也可以在 Redis 之类的地方放 20 个库存 Key。

总之,就是把你的 1000 件库存给他拆开,每个库存段是 50 件库存,比如 stock_01 对应 50 件库存,stock_02 对应 50 件库存。

接着,每秒 1000 个请求过来了,好!此时其实可以是自己写一个简单的随机算法,每个请求都是随机在 20 个分段库存里,选择一个进行加锁。

Bingo!这样就好了,同时可以有最多 20 个下单请求一起执行,每个下单请求锁了一个库存分段,然后在业务逻辑里面,就对数据库或者是 Redis 中的那个分段库存进行操作即可,包括查库存→判断库存是否充足→扣减库存。

这相当于什么呢?相当于一个 20 毫秒,可以并发处理掉 20 个下单请求,那么 1 秒,也就可以依次处理掉 20 * 50 = 1000 个对 iPhone 的下单请求了。

一旦对某个数据做了分段处理之后,有一个坑大家一定要注意:就是如果某个下单请求,咔嚓加锁,然后发现这个分段库存里的库存不足了,此时咋办?

这时你得自动释放锁,然后立马换下一个分段库存,再次尝试加锁后尝试处理。这个过程一定要实现。

分布式锁并发优化方案有什么不足?

不足肯定是有的,最大的不足,很不方便,实现太复杂了:

  • 首先,你得对一个数据分段存储,一个库存字段本来好好的,现在要分为 20 个库存字段。
  • 其次,你在每次处理库存的时候,还得自己写随机算法,随机挑选一个分段来处理。
  • 最后,如果某个分段中的数据不足了,你还得自动切换到下一个分段数据去处理。

这个过程都是要手动写代码实现的,还是有点工作量,挺麻烦的。

不过我们确实在一些业务场景里,因为用到了分布式锁,然后又必须要进行锁并发的优化,又进一步用到了分段加锁的技术方案,效果当然是很好的了,一下子并发性能可以增长几十倍。

该优化方案的后续改进:以我们本文所说的库存超卖场景为例,你要是这么玩,会把自己搞的很痛苦!再次强调,我们这里的库存超卖场景,仅仅只是作为演示场景而已。

作者:中华石杉

中华石杉:十余年 BAT 架构经验,一线互联网公司技术总监。带领上百人团队开发过多个亿级流量高并发系统。现将多年工作中积累下的研究手稿、经验总结整理成文,倾囊相授。微信公众号:石杉的架构笔记(ID:shishan100)。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章