電子發(fā)燒友App
本地加鎖的方式在分布式的場(chǎng)景下不適用，所以本文我們來(lái)探討下如何引入分布式鎖解決本地鎖的問(wèn)題。本篇所有代碼和業(yè)務(wù)基于我的開源項(xiàng)目 PassJava。
本篇主要內(nèi)容如下：
一、本地鎖的問(wèn)題
首先我們來(lái)回顧下本地鎖的問(wèn)題：
目前題目微服務(wù)被拆分成了四個(gè)微服務(wù)。前端請(qǐng)求進(jìn)來(lái)時(shí)，會(huì)被轉(zhuǎn)發(fā)到不同的微服務(wù)。假如前端接收了 10 W 個(gè)請(qǐng)求，每個(gè)微服務(wù)接收 2.5 W 個(gè)請(qǐng)求，假如緩存失效了，每個(gè)微服務(wù)在訪問(wèn)數(shù)據(jù)庫(kù)時(shí)加鎖，通過(guò)鎖（synchronzied 或 lock）來(lái)鎖住自己的線程資源，從而防止緩存擊穿。
這是一種本地加鎖的方式，在分布式情況下會(huì)帶來(lái)數(shù)據(jù)不一致的問(wèn)題：比如服務(wù) A 獲取數(shù)據(jù)后，更新緩存 key =100，服務(wù) B 不受服務(wù) A 的鎖限制，并發(fā)去更新緩存 key = 99，最后的結(jié)果可能是 99 或 100，但這是一種未知的狀態(tài)，與期望結(jié)果不一致 。流程圖如下所示：
基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
視頻教程：https://doc.iocoder.cn/video/
二、什么是分布式鎖
基于上面本地鎖的問(wèn)題，我們需要一種支持分布式集群環(huán)境 下的鎖：查詢 DB 時(shí)，只有一個(gè)線程能訪問(wèn)，其他線程都需要等待第一個(gè)線程釋放鎖資源后，才能繼續(xù)執(zhí)行。
生活中的案例 ：可以把鎖看成房門外的一把鎖，所有并發(fā)線程比作人，他們都想進(jìn)入房間，房間內(nèi)只能有一個(gè)人進(jìn)入。當(dāng)有人進(jìn)入后，將門反鎖，其他人必須等待，直到進(jìn)去的人出來(lái)。
我們來(lái)看下分布式鎖的基本原理，如下圖所示：
我們來(lái)分析下上圖的分布式鎖：
1.前端將 10W 的高并發(fā)請(qǐng)求轉(zhuǎn)發(fā)給四個(gè)題目微服務(wù)。
2.每個(gè)微服務(wù)處理 2.5 W 個(gè)請(qǐng)求。
3.每個(gè)處理請(qǐng)求的線程在執(zhí)行業(yè)務(wù)之前，需要先搶占鎖?？梢岳斫鉃椤罢伎印薄?/p>
4.獲取到鎖的線程在執(zhí)行完業(yè)務(wù)后，釋放鎖?？梢岳斫鉃椤搬尫趴游弧?。
5.未獲取到的線程需要等待鎖釋放。
6.釋放鎖后，其他線程搶占鎖。
7.重復(fù)執(zhí)行步驟 4、5、6。
大白話解釋：所有請(qǐng)求的線程都去同一個(gè)地方“占坑”，如果有坑位，就執(zhí)行業(yè)務(wù)邏輯，沒有坑位，就需要其他線程釋放“坑位”。這個(gè)坑位是所有線程可見的，可以把這個(gè)坑位放到 Redis 緩存或者數(shù)據(jù)庫(kù)，這篇講的就是如何用 Redis 做“分布式坑位”。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能
項(xiàng)目地址：https://github.com/YunaiV/yudao-cloud
視頻教程：https://doc.iocoder.cn/video/
三、Redis 的 SETNX
Redis 作為一個(gè)公共可訪問(wèn)的地方，正好可以作為“占坑”的地方。
用 Redis 實(shí)現(xiàn)分布式鎖的幾種方案，我們都是用 SETNX 命令（設(shè)置 key 等于某 value）。只是高階方案?jìng)鞯膮?shù)個(gè)數(shù)不一樣，以及考慮了異常情況。
我們來(lái)看下這個(gè)命令，SETNX是set If not exist的簡(jiǎn)寫。意思就是當(dāng) key 不存在時(shí)，設(shè)置 key 的值，存在時(shí)，什么都不做。
在 Redis 命令行中是這樣執(zhí)行的：
?
?
set?? ?NX
?
?
我們可以進(jìn)到 redis 容器中來(lái)試下 SETNX 命令。
先進(jìn)入容器：
?
?
docker?exec?-it?<容器?id>?redid-cli
?
?
然后執(zhí)行 SETNX 命令：將 wukong 這個(gè) key 對(duì)應(yīng)的 value 設(shè)置成 1111。
?
?
set?wukong?1111?NX
?
?
返回 OK，表示設(shè)置成功。重復(fù)執(zhí)行該命令，返回 nil表示設(shè)置失敗。
四、青銅方案
我們先用 Redis 的 SETNX 命令來(lái)實(shí)現(xiàn)最簡(jiǎn)單的分布式鎖。
4.1 青銅原理
我們來(lái)看下流程圖：
多個(gè)并發(fā)線程都去 Redis 中申請(qǐng)鎖，也就是執(zhí)行 setnx 命令，假設(shè)線程 A 執(zhí)行成功，說(shuō)明當(dāng)前線程 A 獲得了。
其他線程執(zhí)行 setnx 命令都會(huì)是失敗的，所以需要等待線程 A 釋放鎖。
線程 A 執(zhí)行完自己的業(yè)務(wù)后，刪除鎖。
其他線程繼續(xù)搶占鎖，也就是執(zhí)行 setnx 命令。因?yàn)榫€程 A 已經(jīng)刪除了鎖，所以又有其他線程可以搶占到鎖了。
代碼示例如下，Java 中 setnx 命令對(duì)應(yīng)的代碼為 setIfAbsent。
setIfAbsent 方法的第一個(gè)參數(shù)代表 key，第二個(gè)參數(shù)代表值。
//?1.先搶占鎖
Boolean?lock?=?redisTemplate.opsForValue().setIfAbsent("lock",?"123");
????????if(lock)?{
????????//?2.搶占成功，執(zhí)行業(yè)務(wù)
????????List?typeEntityListFromDb?=?getDataFromDB();
????????//?3.解鎖
????????redisTemplate.delete("lock");
????????return?typeEntityListFromDb;
????????}?else?{
????????//?4.休眠一段時(shí)間
????????sleep(100);
????????//?5.搶占失敗，等待鎖釋放
????????return?getTypeEntityListByRedisDistributedLock();
????????}
?
?
一個(gè)小問(wèn)題：那為什么需要休眠一段時(shí)間？
因?yàn)樵摮绦虼嬖谶f歸調(diào)用，可能會(huì)導(dǎo)致?？臻g溢出。
4.2 青銅方案的缺陷
青銅之所以叫青銅，是因?yàn)樗亲畛跫?jí)的，肯定會(huì)帶來(lái)很多問(wèn)題。
設(shè)想一種家庭場(chǎng)景 ：晚上小空一個(gè)人開鎖進(jìn)入了房間，打開了電燈，然后突然斷電了，小空想開門出去，但是找不到門鎖位置，那小明就進(jìn)不去了，外面的人也進(jìn)不來(lái)。
從技術(shù)的角度看：setnx 占鎖成功，業(yè)務(wù)代碼出現(xiàn)異?；蛘叻?wù)器宕機(jī)，沒有執(zhí)行刪除鎖的邏輯，就造成了死鎖。
那如何規(guī)避這個(gè)風(fēng)險(xiǎn)呢？
設(shè)置鎖的自動(dòng)過(guò)期時(shí)間，過(guò)一段時(shí)間后，自動(dòng)刪除鎖，這樣其他線程就能獲取到鎖了。
五、白銀方案
5.1 生活中的例子
上面提到的青銅方案會(huì)有死鎖問(wèn)題，那我們就用上面的規(guī)避風(fēng)險(xiǎn)的方案來(lái)設(shè)計(jì)下，也就是我們的白銀方案。
還是生活中的例子：小空開鎖成功后，給這款智能鎖設(shè)置了一個(gè)沙漏倒計(jì)時(shí)，沙漏完后，門鎖自動(dòng)打開。即使房間突然斷電，過(guò)一段時(shí)間后，鎖會(huì)自動(dòng)打開，其他人就可以進(jìn)來(lái)了。
5.2 技術(shù)原理圖
和青銅方案不同的地方在于，在占鎖成功后，設(shè)置鎖的過(guò)期時(shí)間，這兩步是分步執(zhí)行的。如下圖所示：
5.3 示例代碼
清理 redis key 的代碼如下
?
?
//?在?10s?以后，自動(dòng)清理?lock redisTemplate.expire("lock",?10,?TimeUnit.SECONDS);
?
?
完整代碼如下：
?
?
//?1.先搶占鎖
Boolean?lock?=?redisTemplate.opsForValue().setIfAbsent("lock",?"123");
????????if(lock)?{
????????//?2.在?10s?以后，自動(dòng)清理?lock
????????redisTemplate.expire("lock",?10,?TimeUnit.SECONDS);
????????//?3.搶占成功，執(zhí)行業(yè)務(wù)
????????List?typeEntityListFromDb?=?getDataFromDB();
????????//?4.解鎖
????????redisTemplate.delete("lock");
????????return?typeEntityListFromDb;
????????}
?
?
5.4 白銀方案的缺陷
白銀方案看似解決了線程異?；蚍?wù)器宕機(jī)造成的鎖未釋放的問(wèn)題，但還是存在其他問(wèn)題：
因?yàn)檎兼i和設(shè)置過(guò)期時(shí)間是分兩步執(zhí)行的，所以如果在這兩步之間發(fā)生了異常，則鎖的過(guò)期時(shí)間根本就沒有設(shè)置成功。
所以和青銅方案有一樣的問(wèn)題：鎖永遠(yuǎn)不能過(guò)期 。
六、黃金方案
6.1 原子指令
上面的白銀方案中，占鎖和設(shè)置鎖過(guò)期時(shí)間是分步兩步執(zhí)行的，這個(gè)時(shí)候，我們可以聯(lián)想到什么：事務(wù)的原子性（Atom）。
原子性 ：多條命令要么都成功執(zhí)行，要么都不執(zhí)行。
將兩步放在一步中執(zhí)行：占鎖+設(shè)置鎖過(guò)期時(shí)間。
Redis 正好支持這種操作：
?
?
#?設(shè)置某個(gè)?key?的值并設(shè)置多少毫秒或秒?過(guò)期。 ????????set?? ?PX?<多少毫秒>?NX ????????或 ????????set? ? ?EX?<多少秒>?NX
?
?
然后可以通過(guò)如下命令查看 key 的變化
?
?
ttl?
?
?
下面演示下如何設(shè)置 key 并設(shè)置過(guò)期時(shí)間。注意：執(zhí)行命令之前需要先刪除 key，可以通過(guò)客戶端或命令刪除。
?
?
#?設(shè)置?key=wukong，value=1111，過(guò)期時(shí)間=5000ms ????????set?wukong?1111?PX?5000?NX ????????#?查看?key?的狀態(tài) ????????ttl?wukong
?
?
執(zhí)行結(jié)果如下圖所示：每運(yùn)行一次 ttl 命令，就可以看到 wukong 的過(guò)期時(shí)間就會(huì)減少。最后會(huì)變?yōu)?-2（已過(guò)期）。
6.2 技術(shù)原理圖
黃金方案和白銀方案的不同之處：獲取鎖的時(shí)候，也需要設(shè)置鎖的過(guò)期時(shí)間，這是一個(gè)原子操作，要么都成功執(zhí)行，要么都不執(zhí)行。如下圖所示：
6.3 示例代碼
設(shè)置 lock 的值等于 123，過(guò)期時(shí)間為 10 秒。如果 10 秒 以后，lock 還存在，則清理 lock。
?
?
setIfAbsent("lock",?"123",?10,?TimeUnit.SECONDS);
?
?
6.4 黃金方案的缺陷
我們還是舉生活中的例子來(lái)看下黃金方案的缺陷。
6.4.1 用戶 A 搶占鎖
用戶 A 先搶占到了鎖，并設(shè)置了這個(gè)鎖 10 秒以后自動(dòng)開鎖，鎖的編號(hào)為 123。
10 秒以后，A 還在執(zhí)行任務(wù)，此時(shí)鎖被自動(dòng)打開了。
6.4.2 用戶 B 搶占鎖
用戶 B 看到房間的鎖打開了，于是搶占到了鎖，設(shè)置鎖的編號(hào)為 123，并設(shè)置了過(guò)期時(shí)間 10 秒。
因房間內(nèi)只允許一個(gè)用戶執(zhí)行任務(wù)，所以用戶 A 和 用戶 B 執(zhí)行任務(wù)產(chǎn)生了沖突。
用戶 A 在 15 s 后，完成了任務(wù)，此時(shí) 用戶 B 還在執(zhí)行任務(wù)。
用戶 A 主動(dòng)打開了編號(hào)為 123的鎖。
用戶 B 還在執(zhí)行任務(wù)，發(fā)現(xiàn)鎖已經(jīng)被打開了。
用戶 B 非常生氣：我還沒執(zhí)行完任務(wù)呢，鎖怎么開了？
6.4.3 用戶 C 搶占鎖
用戶 B 的鎖被 A 主動(dòng)打開后，A 離開房間，B 還在執(zhí)行任務(wù)。
用戶 C 搶占到鎖，C 開始執(zhí)行任務(wù)。
因房間內(nèi)只允許一個(gè)用戶執(zhí)行任務(wù)，所以用戶 B 和 用戶 C 執(zhí)行任務(wù)產(chǎn)生了沖突。
從上面的案例中我們可以知道，因?yàn)橛脩?A 處理任務(wù)所需要的時(shí)間大于 鎖自動(dòng)清理（開鎖）的時(shí)間，所以在自動(dòng)開鎖后，又有其他用戶搶占到了鎖。當(dāng)用戶 A 完成任務(wù)后，會(huì)把其他用戶搶占到的鎖給主動(dòng)打開。
這里為什么會(huì)打開別人的鎖？ 因?yàn)殒i的編號(hào)都叫做 “123”，用戶 A 只認(rèn)鎖編號(hào)，看見編號(hào)為 “123”的鎖就開，結(jié)果把用戶 B 的鎖打開了，此時(shí)用戶 B 還未執(zhí)行完任務(wù)，當(dāng)然生氣了。
七、鉑金方案
7.1 生活中的例子
上面的黃金方案的缺陷也很好解決，給每個(gè)鎖設(shè)置不同的編號(hào) 不就好了～
如下圖所示，B 搶占的鎖是藍(lán)色的，和 A 搶占到綠色鎖不一樣。這樣就不會(huì)被 A 打開了。
做了個(gè)動(dòng)圖，方便理解：
動(dòng)圖演示
靜態(tài)圖更高清，可以看看：
7.2 技術(shù)原理圖
與黃金方案的不同之處：
設(shè)置鎖的過(guò)期時(shí)間時(shí)，還需要設(shè)置唯一編號(hào)。
主動(dòng)刪除鎖的時(shí)候，需要判斷鎖的編號(hào)是否和設(shè)置的一致，如果一致，則認(rèn)為是自己設(shè)置的鎖，可以進(jìn)行主動(dòng)刪除。
7.3 代碼示例
?
?
//?1.生成唯一?id
String?uuid?=?UUID.randomUUID().toString();
//?2.?搶占鎖
????????Boolean?lock?=?redisTemplate.opsForValue().setIfAbsent("lock",?uuid,?10,?TimeUnit.SECONDS);
????????if(lock)?{
????????System.out.println("搶占成功："?+?uuid);
????????//?3.搶占成功，執(zhí)行業(yè)務(wù)
????????List?typeEntityListFromDb?=?getDataFromDB();
????????//?4.獲取當(dāng)前鎖的值
????????String?lockValue?=?redisTemplate.opsForValue().get("lock");
????????//?5.如果鎖的值和設(shè)置的值相等，則清理自己的鎖
????????if(uuid.equals(lockValue))?{
????????System.out.println("清理鎖："?+?lockValue);
????????redisTemplate.delete("lock");
????????}
????????return?typeEntityListFromDb;
????????}?else?{
????????System.out.println("搶占失敗，等待鎖釋放");
????????//?4.休眠一段時(shí)間
????????sleep(100);
????????//?5.搶占失敗，等待鎖釋放
????????return?getTypeEntityListByRedisDistributedLock();
????????}
?
?
1.生成隨機(jī)唯一 id，給鎖加上唯一值。
2.搶占鎖，并設(shè)置過(guò)期時(shí)間為 10 s，且鎖具有隨機(jī)唯一 id。
3.搶占成功，執(zhí)行業(yè)務(wù)。
4.執(zhí)行完業(yè)務(wù)后，獲取當(dāng)前鎖的值。
5.如果鎖的值和設(shè)置的值相等，則清理自己的鎖。
7.4 鉑金方案的缺陷
上面的方案看似很完美，但還是存在問(wèn)題：第 4 步和第 5 步并不是原子性的。
時(shí)刻：0s。線程 A 搶占到了鎖。
時(shí)刻：9.5s。線程 A 向 Redis 查詢當(dāng)前 key 的值。
時(shí)刻：10s。鎖自動(dòng)過(guò)期。
時(shí)刻：11s。線程 B 搶占到鎖。
時(shí)刻：12s。線程 A 在查詢途中耗時(shí)長(zhǎng)，終于拿多鎖的值。
時(shí)刻：13s。線程 A 還是拿自己設(shè)置的鎖的值和返回的值進(jìn)行比較，值是相等的，清理鎖，但是這個(gè)鎖其實(shí)是線程 B 搶占的鎖。
那如何規(guī)避這個(gè)風(fēng)險(xiǎn)呢？鉆石方案登場(chǎng)。
八、鉆石方案
上面的線程 A 查詢鎖和刪除鎖的邏輯不是原子性的，所以將查詢鎖和刪除鎖這兩步作為原子指令操作就可以了。
8.1 技術(shù)原理圖
如下圖所示，紅色圈出來(lái)的部分是鉆石方案的不同之處。用腳本進(jìn)行刪除，達(dá)到原子操作。
8.2 代碼示例
那如何用腳本進(jìn)行刪除呢？
我們先來(lái)看一下這段 Redis 專屬腳本：
?
?
if?redis.call("get",KEYS[1])?==?ARGV[1]
????????then
????????return?redis.call("del",KEYS[1])
????????else
????????return?0
????????end
?
?
這段腳本和鉑金方案的獲取key，刪除key的方式很像。先獲取 KEYS[1] 的 value，判斷 KEYS[1] 的 value 是否和 ARGV[1] 的值相等，如果相等，則刪除 KEYS[1]。
那么這段腳本怎么在 Java 項(xiàng)目中執(zhí)行呢？
分兩步：先定義腳本；用 redisTemplate.execute 方法執(zhí)行腳本。
?
?
//?腳本解鎖
String?script?=?"if?redis.call('get',KEYS[1])?==?ARGV[1]?then?return?redis.call('del',KEYS[1])?else?return?0?end";
????????redisTemplate.execute(new?DefaultRedisScript(script,?Long.class),?Arrays.asList("lock"),?uuid);
?
?
上面的代碼中，KEYS[1] 對(duì)應(yīng)“l(fā)ock”，ARGV[1] 對(duì)應(yīng) “uuid”，含義就是如果 lock 的 value 等于 uuid 則刪除 lock。
而這段 Redis 腳本是由 Redis 內(nèi)嵌的 Lua 環(huán)境執(zhí)行的，所以又稱作 Lua 腳本。
那鉆石方案是不是就完美了呢？有沒有更好的方案呢？
之后我們?cè)賮?lái)介紹另外一種分布式鎖的王者方案：Redisson。
九、總結(jié)
本篇通過(guò)本地鎖的問(wèn)題引申出分布式鎖的問(wèn)題。然后介紹了五種分布式鎖的方案，由淺入深講解了不同方案的改進(jìn)之處。
從上面幾種方案的不斷演進(jìn)的過(guò)程中，知道了系統(tǒng)中哪些地方可能存在異常情況，以及該如何更好地進(jìn)行處理。
舉一反三，這種不斷演進(jìn)的思維模式也可以運(yùn)用到其他技術(shù)中。
下面總結(jié)下上面五種方案的缺陷和改進(jìn)之處。
青銅方案 ：
缺陷：業(yè)務(wù)代碼出現(xiàn)異?；蛘叻?wù)器宕機(jī)，沒有執(zhí)行主動(dòng)刪除鎖的邏輯，就造成了死鎖。
改進(jìn)：設(shè)置鎖的自動(dòng)過(guò)期時(shí)間，過(guò)一段時(shí)間后，自動(dòng)刪除鎖，這樣其他線程就能獲取到鎖了。
白銀方案 ：
缺陷：占鎖和設(shè)置鎖過(guò)期時(shí)間是分步兩步執(zhí)行的，不是原子操作。
改進(jìn)：占鎖和設(shè)置鎖過(guò)期時(shí)間保證原子操作。
黃金方案 ：
缺陷：主動(dòng)刪除鎖時(shí)，因鎖的值都是相同的，將其他客戶端占用的鎖刪除了。
改進(jìn)：每次占用的鎖，隨機(jī)設(shè)為較大的值，主動(dòng)刪除鎖時(shí)，比較鎖的值和自己設(shè)置的值是否相等。
鉑金方案 ：
缺陷：獲取鎖、比較鎖的值、刪除鎖，這三步是非原子性的。中途又可能鎖自動(dòng)過(guò)期了，又被其他客戶端搶占了鎖，導(dǎo)致刪鎖時(shí)把其他客戶端占用的鎖刪了。
改進(jìn)：使用 Lua 腳本進(jìn)行獲取鎖、比較鎖、刪除鎖的原子操作。
鉆石方案 ：
缺陷：非專業(yè)的分布式鎖方案。
改進(jìn)：Redission 分布式鎖。
編輯：黃飛
?
工商網(wǎng)監(jiān)
評(píng)論