SpringCloud(5)之分布式鎖實現

01為什么用分布式鎖

在討論這個問題之前，我們先來看一個業務場景：系統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里面)。

那么，我們只要保證兩台機器加的鎖是同一個鎖，問題不就解決了嗎？此時，就該分布式鎖隆重登場了，分布式鎖的思路是：

在整個系統提供一個全局、唯一的獲取鎖的“東西”，然后每個系統在需要加鎖時，都去問這個“東西”拿到一把鎖，這樣不同的系統拿到的就可以認為是同一把鎖。

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

02基於 Redis 實現分布式鎖

上面分析為啥要使用分布式鎖了，這里我們來具體看看分布式鎖落地的時候應該怎么樣處理。

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

使用Redis做分布式鎖的思路大概是這樣的：在redis中設置一個值表示加了鎖，然后釋放鎖的時候就把這個key刪除。

具體代碼是這樣的：

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

這種方式有幾大要點：

1. 一定要用SET key value NX PX milliseconds 命令如果不用，先設置了值，再設置過期時間，這個不是原子性操作，有可能在設置過期時間之前宕機，會造成死鎖(key永久存在)
2. value要具有唯一性，這個是為了在解鎖的時候，需要驗證value是和加鎖的一致才刪除key。

   這是避免了一種情況：假設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，也提供了分布式鎖的支持。我也非常推薦大家使用，為什么呢？

SET anyLock unique_value NX PX 30000

這里設置的超時時間是30s，假如我超過30s都還沒有完成業務邏輯的情況下，key會過期，其他線程有可能會獲取到鎖。

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

我們來看看redisson是怎么實現的？先感受一下使用redission的爽：

1.  
   Config config = new Config();
2.  
   config.useClusterServers()
3.  
   .setScanInterval( 2000) // 集群狀態掃描間隔時間，單位是毫秒
4.  
   //可以用"rediss://"來啟用SSL連接
5.  
   .addNodeAddress( "redis://127.0.0.1:7000", "redis://127.0.0.1:7001")
6.  
   .addNodeAddress( "redis://127.0.0.1:7002");
7.  
    
8.  
   RedissonClient redisson = Redisson.create(config);
9.  
    
10.  
    RLock
11.  
     
12.  
    lock = redisson.getLock("anyLock");
13.  
    lock.lock();
14.  
    lock.unlock();

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

1. redisson所有指令都通過lua腳本執行，redis支持lua腳本原子性執行
2. redisson設置一個key的默認過期時間為30s,如果某個客戶端持有一個鎖超過了30s怎么辦？
3. redisson中有一個watchdog的概念，翻譯過來就是看門狗，它會在你獲取鎖之后，每隔10秒幫你把key的超時時間設為30s,這樣的話，就算一直持有鎖也不會出現key過期了，其他線程獲取到鎖的問題了。
4. redisson的“看門狗”邏輯保證了沒有死鎖發生。(如果機器宕機了，看門狗也就沒了。此時就不會延長key的過期時間，到了30s之后就會自動過期了，其他線程可以獲取到鎖)

對於redisson更多的用法請參考官方文檔：https://github.com/redisson/redisson/wiki/

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

03基於 zookeeper 實現分布式鎖

常見的分布式鎖實現方案里面，除了使用redis來實現之外，使用zookeeper也可以實現分布式鎖。在介紹zookeeper(下文用zk代替)實現分布式鎖的機制之前，先粗略介紹一下zk是什么東西：

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

zk的模型是這樣的：zk包含一系列的節點，叫做znode，就好像文件系統一樣每個znode表示一個目錄，然后znode有一些特性：

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

2. 臨時節點：客戶端可以建立一個臨時節點，在會話結束或者會話超時后，zookeeper會自動刪除該節點。

3. 臨時節點：客戶端可以建立一個臨時節點，在會話結束或者會話超時后，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都有其優缺點。我們在做技術選型的時候可以根據這些問題作為參考因素。

 

05 基於數據庫的實現方式

基於數據庫的實現方式的核心思想是：在數據庫中創建一個表，表中包含方法名等字段，並在方法名字段上創建唯一索引，想要執行某個方法，就使用這個方法名向表中插入數據，成功插入則獲取鎖，執行完成后刪除對應的行數據釋放鎖。

1.  
   DROP TABLE IF EXISTS `method_lock`;
2.  
   CREATE TABLE `method_lock` (
3.  
   `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主鍵',
4.  
   `method_name` varchar(64) NOT NULL COMMENT '鎖定的方法名',
5.  
   `desc` varchar(255) NOT NULL COMMENT '備注信息',
6.  
   `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
7.  
   PRIMARY KEY (`id`),
8.  
   UNIQUE KEY `uidx_method_name` (`method_name`) USING BTREE
9.  
   ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8 COMMENT='鎖定中的方法';

想要執行某個方法獲取得到鎖，就使用這個方法名向表中插入數據：

INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '測試的methodName'); 

因為我們對method_name做了唯一性約束，這里如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那么我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體內容。

成功插入則獲取鎖，執行完成后刪除對應的行數據釋放鎖：

delete from method_lock where method_name ='methodName'; 

 

注意：這只是使用基於數據庫的一種方法，使用數據庫實現分布式鎖還有很多其他的玩法！

使用基於數據庫的這種實現方式很簡單，但是對於分布式鎖應該具備的條件來說，它有一些問題需要解決及優化：

1. 因為是基於數據庫實現的，數據庫的可用性和性能將直接影響分布式鎖的可用性及性能，所以，數據庫需要雙機部署、數據同步、主備切換；
2. 不具備可重入的特性，因為同一個線程在釋放鎖之前，行數據一直存在，無法再次成功插入數據，所以，需要在表中新增一列，用於記錄當前獲取到鎖的機器和線程信息，在再次獲取鎖的時候，先查詢表中機器和線程信息是否和當前機器和線程相同，若相同則直接獲取鎖；
3. 沒有鎖失效機制，因為有可能出現成功插入數據后，服務器宕機了，對應的數據沒有被刪除，當服務恢復后一直獲取不到鎖，所以，需要在表中新增一列，用於記錄失效時間，並且需要有定時任務清除這些失效的數據；
4. 不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優化獲取邏輯，循環多次去獲取。
5. 在實施的過程中會遇到各種不同的問題，為了解決這些問題，實現方式將會越來越復雜；依賴數據庫需要一定的資源開銷，性能問題需要考慮。

以上是我最近在做項目中去分布式鎖中所學到的知識，在這里分享給大家，歡迎大家斧正。