Redis 分布式锁这个话题似乎烂大街了,不管你是面试还是工作,随处可见,「码哥」为啥还要写呢?
因为网上 99.99% 的文章都没有真正地把分布式锁说清楚,存在很多问题 bug。
今日,「码哥」就跟大家深入分布式锁的 G 点,系统地做一个写好代码掌握技巧的真男人。
在进入「高潮」之前,以下问题就当做「前戏」去思考,你能回答多少?
❝
码哥,说个通俗的例子讲解下什么时候需要分布式锁呢?
精子喷射那一刻,亿级流量冲向卵子,只有一个精子能获得与卵子结合的幸运。
造物主为了保证只有一个「精子」能获得「卵子」的宠幸,当有一个精子进入后,卵子的外壳就会发生变化,将通道关闭把其余的精子阻挡在外。
而多节点构成的集群,就会有多个 JVM 进程,我们获得同样的效果就需要有一个中间人协调,只允许一个 JVM 中的一个线程获得操作共享资源的资格。
分布式锁就是用来控制同一时刻,只有一个 JVM 进程中的一个线程「精子」可以访问被保护的资源「卵子」。
「每一个生命,都是亿级选手中的佼佼者」,加油。
❝
分布式锁应该满足哪些特性?
❝
码哥,我可以使用 SETNX key value 命令是实现「互斥」特性。
这个命令来自于SET if Not eXists的缩写,意思是:如果 key 不存在,则设置 value 给这个key,否则啥都不做。
命令的返回值:
如下场景:
敲代码一天累了,想去放松按摩下肩颈。
168 号技师最抢手,大家喜欢点,所以并发量大,需要分布式锁控制。
同一时刻只允许一个「客户」预约 168 技师。
肖彩机申请 168 技师成功:
> SETNX lock:168 1 (integer) 1 # 获取 168 技师成功
谢霸哥后面到,申请失败:
> SETNX lock 2 (integer) 0 # 客户谢霸哥 2 获取失败
此刻,申请成功的客户就可以享受 168 技师的肩颈放松服务「共享资源」。
享受结束后,要及时释放锁,给后来者享受 168 技师的服务机会。
❝
肖彩机,码哥考考你如何释放锁呢?
很简单,使用 DEL 删除这个 key 就行。
> DEL lock:168 (integer) 1
❝
码哥,你见过「龙」么?我见过,因为我被一条龙服务过。
肖彩机,事情可没这么简单。
这个方案存在一个存在造成「死锁」的问题,造成该问题的场景如下:
这样,这个锁就会一直占用,其他客户就「再也没有」机会获取 168 技师服务了。
❝
码哥,我可以在获取锁成功的时候设置一个「超时时间」
比如设定按摩服务一次 60 分钟,那么在给这个 key 加锁的时候设置 60 分钟过期即可:
> SETNX lock:168 1 // 获取锁 (integer) 1 > EXPIRE lock:168 60 // 60s 自动删除 (integer) 1
这样,到点后锁自动释放,其他客户就可以继续享受 168 技师按摩服务了。
❝
谁要这么写,就糟透了。
「加锁」、「设置超时」是两个命令,他们不是原子操作。
如果出现只执行了第一条,第二条没机会执行就会出现「超时时间」设置失败,依然出现死锁。
比如以下场景导致无法执行第二条指令:
❝
码哥,那咋办,我想被一条龙服务,不能出现死锁啊。
Redis 2.6.12 之后,拓展了 SET 命令的参数,满足了当 key 不存在则设置 value,同时设置超时时间的语义,并且满足原子性。
SET resource_name random_value NX PX 30000
❝
这样我能稳妥的享受一条龙服务了么?
No,还有一种场景会导致释放别人的锁:
有两个关键问题需要解决:
❝
锁的超时时间怎么计算合适呢?
这个时间不能瞎写,一般要根据在测试环境多次测试,然后压测多轮之后,比如计算出平均执行时间 200 ms。
那么锁的超时时间就放大为平均执行时间的 3~5 倍。
❝
为啥要放放大呢?
因为如果锁的操作逻辑中有网络 IO 操作、JVM FullGC 等,线上的网络不会总一帆风顺,我们要给网络抖动留有缓冲时间。
❝
那我设置更大一点,比如设置 1 小时不是更安全?
不要钻牛角,多大算大?
设置时间过长,一旦发生宕机重启,就意味着 1 小时内,分布式锁的服务全部节点不可用。
你要让运维手动删除这个锁么?
只要运维真的不会打你。
❝
有没有完美的方案呢?不管时间怎么设置都不大合适。
我们可以让获得锁的线程开启一个守护线程,用来给快要过期的锁「续航」。
加锁的时候设置一个过期时间,同时客户端开启一个「守护线程」,定时去检测这个锁的失效时间。
如果快要过期,但是业务逻辑还没执行完成,自动对这个锁进行续期,重新设置过期时间。
❝
这个道理行得通,可我写不出。
别慌,已经有一个库把这些工作都封装好了他叫Redisson。
Redisson 是一个 Java 语言实现的 Redis SDK 客户端,在使用分布式锁时,它就采用了「自动续期」的方案来避免锁过期,这个守护线程我们一般也把它叫做「看门狗」线程。
关于 Redisson 的使用与原理分析由于篇幅有限,大家可关注「码哥字节」且听下回分解。
出现释放别人锁的关键在于「无脑执行」DEL指令,所以我们要想办法检查下这个锁是不是自己加的。
解铃还须系铃人
❝
码哥,我在加锁的时候设置一个「唯一标识」作为 value 代表加锁的客户端。
在释放锁的时候,客户端将自己的「唯一标识」与锁上的「标识」比较是否相等,匹配上则删除,否则没有权利释放锁。
伪代码如下:
// 比对 value 与 唯一标识 if (redis.get("lock:168").equals(uuid)){ redis.del("lock:168"); //比对成功则删除 }
❝
有没有想过,这是 GET + DEL 指令组合而成的,这里又会涉及到原子性问题。
复现下情况:
我们是追求极致的男人,所以这里通过 Lua 脚本来实现,这样判断和删除的过程就是原子操作了。
if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1]) else return 0 end
❝
一路优化下来,方案似乎比较「严谨」了,抽象出对应的模型如下。
根据前面的分析,我们已经有了一个「相对严谨」的分布式锁了。
于是「谢霸哥」就写了如下代码将分布式锁运用到项目中,以下是伪代码逻辑:
public void doSomething() { try { redisLock.lock(); // 上锁 // 处理业务 redisLock.unlock(); // 释放锁 } catch (Exception e) { e.printStackTrace(); } }
❝
一旦执行业务逻辑过程中抛出异常,程序就无法走下一步释放锁的流程。
所以释放锁的代码一定要放在 finally{} 块中。
加锁的位置也有问题,如果执行 redisLock.lock() 加锁异常,那么就会执行 finally{} 代码块指令执行解锁,这个时候锁并没有申请成功。
所以 redisLock.lock();应该放在 try 外面。
综上所述,正确代码位置如下 :
public void doSomething() { // 上锁 redisLock.lock(); try { // 处理业务 ... } catch (Exception e) { e.printStackTrace(); } finally { // 释放锁 redisLock.unlock(); } }
❝
可重入锁要如何实现呢?重入之后,超时时间如何设置呢?
当一个线程执行一段代码成功获取锁之后,继续执行时,又遇到加锁的代码,可重入性就就保证线程能继续执行,而不可重入就是需要等待锁释放之后,再次获取锁成功,才能继续往下执行。
用一段代码解释可重入:
public synchronized void a() { b(); } public synchronized void b() { // pass }
假设 X 线程在 a 方法获取锁之后,继续执行 b 方法,如果此时不可重入,线程就必须等待锁释放,再次争抢锁。
说明明是被 X 线程拥有,却还需要等待自己释放锁,然后再去抢锁,这看起来就很奇怪,我释放我自己~
❝
Redisson 类库就是通过 Redis Hash 来实现可重入锁,未来码哥会专门写一篇关于 Redisson 的使用与原理的文章……
当线程拥有锁之后,往后再遇到加锁方法,直接将加锁次数加 1,然后再执行方法逻辑。
退出加锁方法之后,加锁次数再减 1,当加锁次数为 0 时,锁才被真正的释放。
可以看到可重入锁最大特性就是计数,计算加锁的次数。
所以当可重入锁需要在分布式环境实现时,我们也就需要统计加锁次数。
❝
我们可以使用 Redis hash 结构实现,key 表示被锁的共享资源, hash 结构的 fieldKey 的 value 则保存加锁的次数。
通过 Lua 脚本实现原子性,假设 KEYS1 = 「lock」, ARGV「1000,uuid」:
---- 1 代表 true ---- 0 代表 false if (redis.call('exists', KEYS[1]) == 0) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return 1; end ; if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then redis.call('hincrby', KEYS[1], ARGV[2], 1); redis.call('pexpire', KEYS[1], ARGV[1]); return 1; end ; return 0;
加锁代码首先使用 Redis exists 命令判断当前 lock 这个锁是否存在。
如果锁不存在的话,直接使用 hincrby创建一个键为 lock hash 表,并且为 Hash 表中键为 uuid 初始化为 0,然后再次加 1,最后再设置过期时间。
如果当前锁存在,则使用 hexists判断当前 lock 对应的 hash 表中是否存在 uuid 这个键,如果存在,再次使用 hincrby 加 1,最后再次设置过期时间。
最后如果上述两个逻辑都不符合,直接返回。
-- 判断 hash set 可重入 key 的值是否等于 0 -- 如果为 0 代表 该可重入 key 不存在 if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then return nil; end ; -- 计算当前可重入次数 local counter = redis.call('hincrby', KEYS[1], ARGV[1], -1); -- 小于等于 0 代表可以解锁 if (counter > 0) then return 0; else redis.call('del', KEYS[1]); return 1; end ; return nil;
首先使用 hexists 判断 Redis Hash 表是否存给定的域。
如果 lock 对应 Hash 表不存在,或者 Hash 表不存在 uuid 这个 key,直接返回 nil。
若存在的情况下,代表当前锁被其持有,首先使用 hincrby使可重入次数减 1 ,然后判断计算之后可重入次数,若小于等于 0,则使用 del 删除这把锁。
解锁代码执行方式与加锁类似,只不过解锁的执行结果返回类型使用 Long。这里之所以没有跟加锁一样使用 Boolean ,这是因为解锁 lua 脚本中,三个返回值含义如下:
❝
码哥,到这里分布式锁「很完美了」吧,没想到分布式锁这么多门道。
路还很远,之前分析的场景都是,锁在「单个」Redis 实例中可能产生的问题,并没有涉及到 Redis 的部署架构细节。
我们通常使用「Cluster 集群」或者「哨兵集群」的模式部署保证高可用。
这两个模式都是基于「主从架构数据同步复制」实现的数据同步,而 Redis 的主从复制默认是异步的。
我们试想下如下场景会发生什么问题:
虽然这个概率极低,但是我们必须得承认这个风险的存在。
❝
Redis 的作者提出了一种解决方案,叫 Redlock(红锁)
Redis 的作者为了统一分布式锁的标准,搞了一个 Redlock,算是 Redis 官方对于实现分布式锁的指导规范,
https://redis.io/topics/distlock,但是这个 Redlock 也被国外的一些分布式专家给喷了。
因为它也不完美,有“漏洞”。
红锁是不是这个?
泡面吃多了你,Redlock 红锁是为了解决主从架构中锁丢失而提出的一种算法。
Redlock 的方案基于 2 个前提:
也就是说,想用使用 Redlock,你至少要部署 5 个 Redis 实例,而且都是主库,它们之间没有任何关系,都是一个个孤立的实例。
一个客户端要获取锁有 5 个步骤:
❝
为什么要部署多个实例并加锁呢?
本质是为了高可用和容错,即使部分实例宕机,大多数实例加锁成功,整个分布式锁服务依然可用。
❝
为啥在第三步要计算加锁的累计时间?
因为多多个节点加锁,耗时可能会比较长,网络中可能存在丢包、超时等现象。
即使大多数节点获取锁成功,假如获取锁的总时间已经超过锁的有效时间,这个锁已经没有意义了。
❝
为什么释放锁要操作所有节点,即使有的节点加锁未成功?
因为有可能客户端在 Redis 实例上加锁成功,只是客户端读取响应的时候失败导致客户端以为加锁失败。
为了安全的清理锁,就需要向每个节点发送释放锁的请求。
❝
Redlock 这么完美?那他解决了 Redis 主从架构节点异常宕机导致锁丢失的问题了么?
事情可没这么简单,Redis 作者把这个方案提出后,受到了业界著名的分布式系统专家的质疑。
两人好比神仙打架,两人一来一回论据充足的对一个问题提出很多论断……
由于篇幅原因,关于 两人的争论分析以及 Redssion 对分布式锁的封装以及 Redlock 的实现我们下期再见。
预知后事如何,且听下回分解…
完工,我建议你合上屏幕,自己在脑子里重新过一遍,每一步都在做什么,为什么要做,解决什么问题。
我们一起从头到尾梳理了一遍 Redis 分布式锁中的各种门道,其实很多点是不管用什么做分布式锁都会存在的问题,重要的是思考的过程。
对于系统的设计,每个人的出发点都不一样,没有完美的架构,没有普适的架构,但是在完美和普适能平衡的很好的架构,就是好的架构。
关于 Redlock 的争论主要集中在如下几点: