1. 程式人生 > >一起來學習分散式鎖

一起來學習分散式鎖

為什麼要用分散式鎖

我們先來看一個業務場景:

系統 A 是一個電商系統,目前是一臺機器部署,系統中有一個使用者下訂單的介面,但是使用者下訂單之前一定要去檢查一下庫存,確保庫存 足夠了才會給使用者下單。

由於系統有一定的併發,所以會預先將商品的庫存儲存在 redis 中,使用者下單的時候會更新 redis 的庫存。

此時系統架構如下:

但是這樣一來會產生一個問題:假如某個時刻,redis 裡面的某個商品庫存為 1,此時兩個請求同時到來,其中一個請求執行到上圖 的第 3 步,更新資料庫的庫存為 0,但是第 4 步還沒有執行。 而另外一個請求執行到了第 2 步,發現庫存還是 1,就繼續執行第 3 步。 這樣的結果,是導致賣出了 2 個商品,然而其實庫存只有 1 個。

很明顯不對啊!這就是典型的庫存超賣問題。

此時,我們很容易想到解決方案:用鎖把 2、3、4 步鎖住,讓他們執行完之後,另一個執行緒才能進來執行第 2 步。

按照上面的圖,在執行第 2 步時,使用 Java 提供的 synchronized 或者 ReentrantLock 來鎖住,然後在第 4 步執行完之後才釋放鎖。

這樣一來,2、3、4 這 3 個步驟就被 “鎖” 住了,多個執行緒之間只能序列化執行。

但是好景不長,整個系統的併發飆升,一臺機器扛不住了。現在要增加一臺機器,如下圖:

增加機器之後,系統變成上圖所示,我的天!

假設此時兩個使用者的請求同時到來,但是落在了不同的機器上,那麼這兩個請求是可以同時執行了,還是會出現庫存超賣的問題。

為什麼呢?因為上圖中的兩個 A 系統,執行在兩個不同的 JVM 裡面,他們加的鎖只對屬於自己 JVM 裡面的執行緒有效,對於其他 JVM 的執行緒是無 效的。 因此,這裡的問題是:Java 提供的原生鎖機制在多機部署場景下失效了

這是因為兩臺機器加的鎖不是同一個鎖 (兩個鎖在不同的 JVM 裡面)。

那麼,我們只要保證兩臺機器加的鎖是同一個鎖,問題不就解決了嗎?

此時,就該分散式鎖隆重登場了,分散式鎖的思路是: 在整個系統提供一個全域性、唯一的獲取鎖的 “東西”,然後每個系統在需要加鎖時,都去問這個 “東西” 拿到一把鎖,這樣不 同的系統拿到的就可以認為是同一把鎖。

至於這個 “東西”,可以是 Redis、Zookeeper,也可以是 資料庫。 文字描述不太直觀,我們來看下圖:

通過上面的分析,我們知道了庫存超賣場景在分散式部署系統的情況下使用 Java 原生的鎖機制無法保證執行緒安全,所以我們需要用到分佈 式鎖的方案。

那麼,如何實現分散式鎖呢?接著往下看!

基於 Redis 實現分散式鎖

上面分析為啥要使用分散式鎖了,這裡我們來具體看看分散式鎖落地的時候應該怎麼樣處理。

最常見的一種方案就是使用 Redis 做分散式鎖。

使用 Redis 做分散式鎖的思路大概是這樣的:在 redis 中設定一個值表示加了鎖,然後釋放鎖的時候就把這個 key 刪除。

具體程式碼是這樣的:

// 獲取鎖
// NX是指如果key不存在就成功,key存在返回false,PX可以指定過期時間
SET anyLock unique_value NX PX 
30000
// 釋放鎖:通過執行一段lua指令碼
// 釋放鎖涉及到兩條指令,這兩條指令不是原子性的
// 需要用到redis的lua指令碼支援特性,redis執行lua指令碼是原子性的
if
	redis.call("get",KEYS[1])== ARGV[1] then   
	return redis.call("del",KEYS[1])
else   
	return 0
end

這種方式有幾大要點:

  • 一定要用 SET key value NX PX milliseconds 命令。如果不用,先設定了值,再設定過期時間,這個不是原子性操作,有可能在設定過期時間之前宕機,會造成死鎖 (key 永久存在)

  • value 要具有唯一性。這個是為了在解鎖的時候,需要驗證 value 是和加鎖的一致才刪除 key。

PS: 這裡還有一個問題:假設 A 獲取了鎖,過期時間 30s,此時 35s 之後,鎖已經自動釋放了,A 去釋放鎖,但是此時可能 B 獲取了鎖。A 客戶端 就不能刪除 B 的鎖了。

除了要考慮客戶端要怎麼實現分散式鎖之外,還需要考慮 redis 的部署問題。

redis 有 3 種部署方式:

  • 單機模式
  • master-slave + sentinel 選舉模式
  • redis cluster 模式

使用 redis 做分散式鎖的缺點在於:如果採用單機部署模式,會存在單點問題,只要 redis 故障了。加鎖就不行了。

採用 master-slave 模式,加鎖的時候只對一個節點加鎖,即便通過 sentinel 做了高可用,但是如果 master 節點故障了,發生主從切換,此時就會有可能出現鎖丟失的問題。

基於以上的考慮,其實 redis 的作者也考慮到這個問題,他提出了一個 RedLock 的演算法,這個演算法的意思大概是這樣的:

假設 redis 的部署模式是 redis cluster,總共有 5 個 master 節點,通過以下步驟獲取一把鎖:

  • 獲取當前時間戳,單位是毫秒
  • 輪流嘗試在每個 master 節點上建立鎖,過期時間設定較短,一般就幾十毫秒
  • 嘗試在大多數節點上建立一個鎖,比如 5 個節點就要求是 3 個節點(n / 2 +1)
  • 客戶端計算建立好鎖的時間,如果建立鎖的時間小於超時時間,就算建立成功了
  • 要是鎖建立失敗了,那麼就依次刪除這個鎖
  • 只要別人建立了一把分散式鎖,你就得不斷輪詢去嘗試獲取鎖

但是這樣的這種演算法還是頗具爭議的,可能還會存在不少的問題,無法保證加鎖的過程一定正確。

另一種方式:Redisson

此外,實現 Redis 的分散式鎖,除了自己基於 redis client 原生 api 來實現之外,還可以使用開源框架:Redission

Redisson 是一個企業級的開源 Redis Client,也提供了分散式鎖的支援。我也非常推薦大家使用,為什麼呢?

回想一下上面說的,如果自己寫程式碼來通過 redis 設定一個值,是通過下面這個命令設定的。

SET anyLock unique_value NX PX 30000

這裡設定的超時時間是 30s,假如我超過 30s 都還沒有完成業務邏輯的情況下,key 會過期,其他執行緒有可能會獲取到鎖。

這樣一來的話,第一個執行緒還沒執行完業務邏輯,第二個執行緒進來了也會出現執行緒安全問題。所以我們還需要額外的去維護這個過期時間,太麻煩了~

我們來看看 redisson 是怎麼實現的?先感受一下使用 redission 的爽:

Config config = new Config();
config.useClusterServers()
.addNodeAddress("redis://192.168.31.101:7001")
.addNodeAddress("redis://192.168.31.101:7002")
.addNodeAddress("redis://192.168.31.101:7003")
.addNodeAddress("redis://192.168.31.102:7001")
.addNodeAddress("redis://192.168.31.102:7002")
.addNodeAddress("redis://192.168.31.102:7003");

RedissonClient redisson = Redisson.create(config);

RLock lock = redisson.getLock("anyLock");
lock.lock();
lock.unlock();

就是這麼簡單,我們只需要通過它的 api 中的 lock 和 unlock 即可完成分散式鎖,他幫我們考慮了很多細節:

  • redisson 所有指令都通過 lua 指令碼執行,redis 支援 lua 指令碼原子性執行
  • redisson 設定一個 key 的預設過期時間為 30s, 如果某個客戶端持有一個鎖超過了 30s 怎麼辦?

redisson 中有一個 watchdog 的概念,翻譯過來就是看門狗,它會在你獲取鎖之後,每隔 10 秒幫你把 key 的超時時間設為 30s

這樣的話,就算一直持有鎖也不會出現 key 過期了,其他執行緒獲取到鎖的問題了。

redisson 的 “看門狗” 邏輯保證了沒有死鎖發生 (如果機器宕機了,看門狗也就沒了。此時就不會延長 key 的過期時間,到了 30s 之後就會自動過期了,其他執行緒可以獲取到鎖)

這裡稍微貼出來其實現程式碼:

另外,redisson 還提供了對 redlock 演算法的支援,

它的用法也很簡單:

RedissonClient     redisson    = Redisson.create(config);
RLock lock1 = redisson.getFairLock("lock1");
RLock lock2 = redisson.getFairLock("lock2");
RLock lock3 = redisson.getFairLock("lock3");
RedissonRedLock     multiLock = new RedissonRedLock(lock1,lock2,lock3);
multiLock.lock();
multiLock.unlock();
小結

本節分析了使用 redis 作為分散式鎖的具體落地方案,以及其一些侷限性,然後介紹了一個 redis 的客戶端框架 redisson,這也是推薦大家使用的,比自己寫程式碼實現會少 care 很多細節。

基於 zookeeper 實現分散式鎖

常見的分散式鎖實現方案裡面,除了使用 redis 來實現之外,使用 zookeeper 也可以實現分散式鎖。

在介紹 zookeeper (下文用 zk 代替) 實現分散式鎖的機制之前,先粗略介紹一下 zk 是什麼東西:

Zookeeper 是一種提供配置管理、分散式協同以及命名的中心化服務。

zk 的模型是這樣的:zk 包含一系列的節點,叫做 znode,就好像檔案系統一樣每個 znode 表示一個目錄,然後 znode 有一些特性:

  • 有序節點:假如當前有一個父節點為 /lock,我們可以在這個父節點下面建立子節點;zookeeper 提供了一個可選的有序特性,例如我們可以建立子節點 “/lock/node-” 並且指明有序,那麼 zookeeper 在生成子節點時會根據 當前的子節點數量自動新增整數序號。也就是說,如果是第一個建立的子節點,那麼生成的子節點為 /lock/node-0000000000,下一個節點則為 /lock/node-0000000001,依次類推。

  • 臨時節點:客戶端可以建立一個臨時節點,在會話結束或者會話超時後,zookeeper 會自動刪除該節點。

  • 事件監聽:在讀取資料時,我們可以同時對節點設定事件監聽,當節點資料或結構變化時,zookeeper 會通知客戶端。當前 zookeeper 有如下四種事件:

    • 節點建立
    • 節點刪除
    • 節點資料修改
    • 子節點變更

基於以上的一些 zk 的特性,我們很容易得出使用 zk 實現分散式鎖的落地方案:

  1. 使用 zk 的臨時節點和有序節點,每個執行緒獲取鎖就是在 zk 建立一個臨時有序的節點,比如在 /lock/ 目錄下。
  2. 建立節點成功後,獲取 /lock 目錄下的所有臨時節點,再判斷當前執行緒建立的節點是否是所有的節點的序號最小的節點
  3. 如果當前執行緒建立的節點是所有節點序號最小的節點,則認為獲取鎖成功。
  4. 如果當前執行緒建立的節點不是所有節點序號最小的節點,則對節點序號的前一個節點新增一個事件監聽。

比如當前執行緒獲取到的節點序號為 /lock/003, 然後所有的節點列表為 [/lock/001,/lock/002,/lock/003], 則對 /lock/002 這個節點 新增一個事件監聽器。

如果鎖釋放了,會喚醒下一個序號的節點,然後重新執行第 3 步,判斷是否自己的節點序號是最小。

比如 /lock/001 釋放了,/lock/002 監聽到事件,此時節點集合為 [/lock/002,/lock/003], 則 /lock/002 為最小序號節點,獲取到鎖。

整個過程如下:

具體的實現思路就是這樣,至於程式碼怎麼寫,這裡比較複雜就不貼出來了。

兩種方案的優缺點比較

學完了兩種分散式鎖的實現方案之後,本節需要討論的是 redis 和 zk 的實現方案中各自的優缺點。

對於 redis 的分散式鎖而言,它有以下缺點:

  • 它獲取鎖的方式簡單粗暴,獲取不到鎖直接不斷嘗試獲取鎖,比較消耗效能。
  • 另外來說的話,redis 的設計定位決定了它的資料並不是強一致性的,在某些極端情況下,可能會出現問題。鎖的模型不夠健壯
  • 即便使用 redlock 演算法來實現,在某些複雜場景下,也無法保證其實現 100% 沒有問題,關於 redlock 的討論可以看 How to do distributed locking
  • redis 分散式鎖,其實需要自己不斷去嘗試獲取鎖,比較消耗效能。

但是另一方面使用 redis 實現分散式鎖在很多企業中非常常見,而且大部分情況下都不會遇到所謂的 “極端複雜場景”

所以使用 redis 作為分散式鎖也不失為一種好的方案,最重要的一點是 redis 的效能很高,可以支撐高併發的獲取、釋放鎖操作。

對於 zk 分散式鎖而言:

  • zookeeper 天生設計定位就是分散式協調,強一致性。鎖的模型健壯、簡單易用、適合做分散式鎖

如果獲取不到鎖,只需要新增一個監聽器就可以了,不用一直輪詢,效能消耗較小。

  • 但是 zk 也有其缺點:如果有較多的客戶端頻繁的申請加鎖、釋放鎖,對於 zk 叢集的壓力會比較大

總結

綜上所述,redis 和 zookeeper 都有其優缺點。我們在做技術選型的時候可以根據這些問題作為參考因素。

一些建議:

通過前面的分析,實現分散式鎖的兩種常見方案:redis 和 zookeeper,他們各有千秋。應該如何選型呢?

就個人而言的話,我比較推崇 zk 實現的鎖。

因為 redis 是有可能存在隱患的,可能會導致資料不對的情況。但是,怎麼選用要看具體在公司的場景了。

如果公司裡面有 zk 叢集條件,優先選用 zk 實現,但是如果說公司裡面只有 redis 叢集,沒有條件搭建 zk 叢集。

那麼其實用 redis 來實現也可以,另外還可能是系統設計者考慮到了系統已經有 redis,但是又不希望再次引入一些外部依賴的情況下 ,可以選用 redis。

這個是要系統設計者基於架構的考慮了。