72 分布式鎖

什么是分布式鎖

分布式鎖 = 分布式 + 鎖。那么分布式是指的什么呢？鎖又是鎖的誰呢？在業(yè)務(wù)開發(fā)中我們經(jīng)常會(huì)聽到分布式分布式的概念，分布式也很簡(jiǎn)單，通俗的來說就是你具有多個(gè)服務(wù)器，每個(gè)服務(wù)器上運(yùn)行的程序是一樣的，用戶的每一次請(qǐng)求，都會(huì)平衡的分配到隨機(jī)的一個(gè)服務(wù)器中進(jìn)行處理。那么這樣的話就會(huì)導(dǎo)致一個(gè)問題，那就是并發(fā)沖突和數(shù)據(jù)不一致等問題。下面結(jié)合一個(gè)簡(jiǎn)單的小例子來介紹一下分布式環(huán)境下不使用分布式鎖會(huì)造成什么問題。

假設(shè)你運(yùn)營(yíng)著一個(gè)在線電商平臺(tái)，某個(gè)商品（商品ID為 product123）的庫(kù)存為10件。當(dāng)用戶在下單時(shí)，系統(tǒng)會(huì)檢查庫(kù)存，確定庫(kù)存是否充足，然后減少庫(kù)存并生成訂單。為了應(yīng)對(duì)大量并發(fā)請(qǐng)求，你的系統(tǒng)使用了多臺(tái)服務(wù)器來處理訂單請(qǐng)求。

用戶1（請(qǐng)求在服務(wù)器A上處理）和 用戶2（請(qǐng)求在服務(wù)器B上處理）同時(shí)發(fā)出購(gòu)買請(qǐng)求。當(dāng)前庫(kù)存：10件

服務(wù)器A接收到用戶1的請(qǐng)求，并查詢數(shù)據(jù)庫(kù)中的庫(kù)存，此時(shí)庫(kù)存為10件。

服務(wù)器B也接收到用戶2的請(qǐng)求，并同時(shí)查詢數(shù)據(jù)庫(kù)中的庫(kù)存，此時(shí)庫(kù)存也是10件。

此時(shí)，兩個(gè)服務(wù)器節(jié)點(diǎn)都“看到”庫(kù)存為10件。

服務(wù)器A為用戶1生成了訂單，并將庫(kù)存減少1。庫(kù)存應(yīng)減少為9件。

與此同時(shí)，服務(wù)器B為用戶2生成了訂單，并將庫(kù)存也減少1，認(rèn)為庫(kù)存現(xiàn)在也是9件。

• 服務(wù)器A將新的庫(kù)存9件更新回?cái)?shù)據(jù)庫(kù)。
• 服務(wù)器B將新的庫(kù)存9件（根據(jù)它的視角）更新回?cái)?shù)據(jù)庫(kù)。

最終結(jié)果：雖然兩個(gè)用戶下單并減少庫(kù)存，但兩臺(tái)服務(wù)器并沒有意識(shí)到對(duì)方的操作，因此它們都認(rèn)為庫(kù)存應(yīng)該從10減少到9，而不是從10減少到8。

實(shí)際發(fā)生的問題是，兩個(gè)用戶都成功購(gòu)買了商品，但庫(kù)存實(shí)際上只減少了1件，而不是2件。這就是庫(kù)存超賣的現(xiàn)象。

庫(kù)存最終顯示為9件，而實(shí)際上它應(yīng)該顯示為8件，意味著庫(kù)存被錯(cuò)誤地記錄，系統(tǒng)允許用戶購(gòu)買超過實(shí)際庫(kù)存量的商品。

分布式鎖保證了在分布式系統(tǒng)環(huán)境下，一個(gè)方法在同一時(shí)間只能被一個(gè)機(jī)器的一個(gè)線程執(zhí)行；

分布式鎖應(yīng)該具備的品質(zhì)

課本上的概念直接列出，讓人看了好似懂了又好似沒懂。分布式鎖簡(jiǎn)單的來說就是為了在不同服務(wù)器上的相同方法只能有一個(gè)在某一時(shí)刻運(yùn)行就是了，我們需要鎖住一些資源，讓其達(dá)到這種效果，無論是什么，都會(huì)涉及到六個(gè)字：高可用高性能，這個(gè)也不例外。這個(gè)分布式鎖需要保證高可用的獲取鎖和釋放鎖，也需要保證高性能的獲取鎖和釋放鎖。同時(shí)為了避免一些意外情況導(dǎo)致某線程一直占用鎖，我們需要保證分布式鎖具有過期時(shí)間，從而避免死鎖。

• 1、在分布式系統(tǒng)環(huán)境下，一個(gè)方法在同一時(shí)間只能被一個(gè)機(jī)器的一個(gè)線程執(zhí)行；
• 2、高可用的獲取鎖與釋放鎖；
• 3、高性能的獲取鎖與釋放鎖；
• 4、具備可重入特性；
• 5、具備鎖失效機(jī)制，防止死鎖；
• 6、具備非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗。

實(shí)現(xiàn)方式

目前我們接觸到的很多大型網(wǎng)站都是基于分布式環(huán)境下開發(fā)的，但是有一個(gè)理論被稱為CAP理論，這個(gè)理論告訴我們，**任何一個(gè)分布式系統(tǒng)都無法同時(shí)保證系統(tǒng)的一致性、可用性和分區(qū)容錯(cuò)性。**所以很多分布式系統(tǒng)都是選擇犧牲一定的強(qiáng)一致性來得到高可用和高性能這一目標(biāo)，它們選擇系統(tǒng)只要保證最終一致性即可。

在很多的分布式場(chǎng)景中，為了達(dá)到最終一致性需要很多的技術(shù)支持，比如：分布式事務(wù)和分布式鎖等等。這里我們先詳細(xì)的介紹一下分布式鎖的實(shí)現(xiàn)方式，分布式鎖的實(shí)現(xiàn)一般分為三個(gè)大類：

1. 基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖；
2. 基于緩存實(shí)現(xiàn)分布式鎖；
3. 基于ZooKeeper實(shí)現(xiàn)分布式鎖；

接下來我們一一介紹。

在介紹之前，我們先仔細(xì)思考一下鎖的概念，什么是鎖呢？鎖只是一個(gè)概念，它不涉及到一個(gè)具體的事物。任何只要能保證唯一性的都可以作為鎖，我們仔細(xì)想想什么能保證唯一性呢？沒錯(cuò)，就是數(shù)據(jù)庫(kù)中的ID和Redis中的setnx，只要插入了兩個(gè)一樣的就會(huì)失敗，這就是等價(jià)于獲取鎖失敗了。

基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖

通過上面的介紹，那么這個(gè)就很簡(jiǎn)單了，就是創(chuàng)建一個(gè)表，這個(gè)表就是為了分布式系統(tǒng)用來獲取鎖的，比如就創(chuàng)建了這個(gè)：

CREATE TABLE `distributed_lock` (`lock_key` VARCHAR(64) NOT NULL PRIMARY KEY,`lock_value` VARCHAR(64) NOT NULL,`expires_at` TIMESTAMP NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

如果這個(gè)線程想獲取到這個(gè)鎖，就在這個(gè)表中插入一條數(shù)據(jù)，其中l(wèi)ock_key為該線程需要對(duì)這個(gè)數(shù)據(jù)進(jìn)行操作的ID，比如訂單ID等等

在每個(gè)分布式節(jié)點(diǎn)中，當(dāng)需要對(duì)某個(gè)共享資源進(jìn)行操作時(shí)，我們會(huì)嘗試向 distributed_lock 表中插入一條記錄。如果插入成功，則表示獲取了鎖，可以安全地執(zhí)行操作。如果插入失敗，則說明鎖已被其他節(jié)點(diǎn)占用。

INSERT INTO `distributed_lock` (`lock_key`, `lock_value`, `expires_at`)
VALUES ('product_123', 'UUID-xxxx', DATE_ADD(NOW(), INTERVAL 10 SECOND))
ON DUPLICATE KEY UPDATE`lock_value` = IF(`expires_at` < NOW(), 'UUID-xxxx', `lock_value`),`expires_at` = IF(`expires_at` < NOW(), DATE_ADD(NOW(), INTERVAL 10 SECOND), `expires_at`);

到了評(píng)價(jià)這個(gè)方法的優(yōu)劣的時(shí)候了，首先這個(gè)是基于MySQL的，那就是外存中的，不用說效率低，效率低帶來的結(jié)果就是并發(fā)性不高，就不適合高并發(fā)的情況，但是該方法方便，但是一般不用。

基于 MySQL 的分布式鎖適合那些并發(fā)量不大、鎖的粒度較粗的場(chǎng)景，如任務(wù)調(diào)度、定時(shí)任務(wù)等。對(duì)于高并發(fā)、低延遲要求較高的場(chǎng)景，建議使用更高效的分布式鎖實(shí)現(xiàn)，如 Redis 或 ZooKeeper。

ON DUPLICATE KEY UPDATE：這個(gè)語(yǔ)句的作用是在插入新記錄時(shí)，如果 lock_key 已經(jīng)存在（比如因?yàn)橹麈I或唯一約束沖突），則不會(huì)重新插入，而是執(zhí)行更新操作。換句話說，如果已經(jīng)有人持有了鎖，這里會(huì)判斷鎖是否已經(jīng)過期，如果過期了就讓當(dāng)前請(qǐng)求獲取鎖。

基于Redis實(shí)現(xiàn)分布式鎖

基于setnx實(shí)現(xiàn)分布式鎖

set if not exist = setnx；

1. 加鎖：執(zhí)行setnx，若成功再執(zhí)行expire添加過期時(shí)間
2. 解鎖：執(zhí)行delete命令

SETNX lock_key unique_value
EXPIRE lock_key 10

這里會(huì)存在一些問題，首先就是這事兩個(gè)操作，不是原子性的，如果客戶端在執(zhí)行 SETNX 后崩潰，EXPIRE 命令無法執(zhí)行，導(dǎo)致這個(gè)鎖永遠(yuǎn)不會(huì)自動(dòng)釋放，造成死鎖問題。

我們可以通過這個(gè)來解決：set nx ex

SET lock_key unique_value NX EX 10

這個(gè)是原子性的。

同時(shí)這里還有一個(gè)過期時(shí)間的問題，就是我獲取到鎖的這個(gè)線程，無法在過期時(shí)間內(nèi)完成這個(gè)任務(wù)，導(dǎo)致別的線程獲得了鎖，從而又導(dǎo)致了分布式鎖的問題。

我們可以通過自動(dòng)續(xù)期（檢查當(dāng)前線程是否完成了任務(wù)，如果沒有完成就自動(dòng)的延長(zhǎng)過期時(shí)間），我們也可以采用更成熟的比如redisson，該提供了更成熟的分布式鎖的設(shè)計(jì)。

基于Redis的Lua腳本能力

使用 SETNX 創(chuàng)建鎖時(shí)，如果鎖被客戶端成功獲取并持有，當(dāng)客戶端任務(wù)執(zhí)行完畢后需要手動(dòng)釋放鎖。然而，如果客戶端在釋放鎖之前崩潰或者出現(xiàn)了錯(cuò)誤，可能會(huì)導(dǎo)致鎖未被正確釋放，或者其他客戶端錯(cuò)誤地釋放了本不屬于它的鎖。

使用 DEL 命令來釋放鎖時(shí)，必須確保只有持有鎖的客戶端才可以釋放它。為此，可以將 unique_value 設(shè)置為唯一值（如 UUID），并通過 Lua 腳本確保只有在持有鎖的客戶端才能刪除鎖。

if redis.call("GET", "lock_key") == "unique_value" thenreturn redis.call("DEL", "lock_key")
elsereturn 0
end

基于Redisson實(shí)現(xiàn)分布式鎖

參考資料

• Redis分布式鎖-這一篇全了解(Redission實(shí)現(xiàn)分布式鎖完美方案)
• 7年一線互聯(lián)網(wǎng)經(jīng)驗(yàn)，超愛圖解底層原理，全棧一枚

重點(diǎn)關(guān)注這個(gè)方式實(shí)現(xiàn)，在以后會(huì)經(jīng)常使用這個(gè)Redisson來實(shí)現(xiàn)分布式鎖。

基于Zookeeper實(shí)現(xiàn)分布式鎖

優(yōu)點(diǎn)：不必多說，可以保證高可用，畢竟是專業(yè)的，Curator框架已原生支持系列分布式鎖命令，使用簡(jiǎn)單

缺點(diǎn)：也不必多說，成本高，需要單獨(dú)維護(hù)一套ZK集群。