分佈式鎖初窺-分佈式鎖的三種實現方式

分佈式鎖應該具有哪些條件

在分析分佈式鎖的三種實現方式以前，先了解一下分佈式鎖應該具有哪些條件：

1. 在分佈式系統環境下，一個方法在同一時間只能被一個機器的一個線程執行；
2. 高可用的獲取鎖與釋放鎖；
3. 高性能的獲取鎖與釋放鎖；
4. 具有可重入特性；
5. 具有鎖失效機制，防止死鎖；
6. 具有非阻塞鎖特性，即沒有獲取到鎖將直接返回獲取鎖失敗。

分佈式鎖的三種實現方式

目前幾乎不少大型網站及應用都是分佈式部署的，分佈式場景中的數據一致性問題一直是一個比較重要的話題。分佈式的CAP理論告訴咱們「任何一個分佈式系統都沒法同時知足一致性（Consistency）、可用性（Availability）和分區容錯性（Partition tolerance），最多隻能同時知足兩項。」因此，不少系統在設計之初就要對這三者作出取捨。在互聯網領域的絕大多數的場景中，都須要犧牲強一致性來換取系統的高可用性，系統每每只須要保證「最終一致性」，只要這個最終時間是在用戶能夠接受的範圍內便可。

在不少場景中，咱們爲了保證數據的最終一致性，須要不少的技術方案來支持，好比分佈式事務、分佈式鎖等。有的時候，咱們須要保證一個方法在同一時間內只能被同一個線程執行。

基於數據庫實現分佈式鎖；
基於緩存（Redis等）實現分佈式鎖；
基於Zookeeper實現分佈式鎖；

基於數據庫的實現方式

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

1. 建立一個表

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

2. 想要執行某個方法，就使用這個方法名向表中插入數據：

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

由於咱們對method_name作了惟一性約束，這裏若是有多個請求同時提交到數據庫的話，數據庫會保證只有一個操做能夠成功，那麼咱們就能夠認爲操做成功的那個線程得到了該方法的鎖，能夠執行方法體內容。

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

delete from method_lock where method_name ='methodName';

注意：這只是使用基於數據庫的一種方法，使用數據庫實現分佈式鎖還有不少其餘的玩法！

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

1. 由於是基於數據庫實現的，數據庫的可用性和性能將直接影響分佈式鎖的可用性及性能，因此，數據庫須要雙機部署、數據同步、主備切換；

2. 不具有可重入的特性，由於同一個線程在釋放鎖以前，行數據一直存在，沒法再次成功插入數據，因此，須要在表中新增一列，用於記錄當前獲取到鎖的機器和線程信息，在再次獲取鎖的時候，先查詢表中機器和線程信息是否和當前機器和線程相同，若相同則直接獲取鎖；

3. 沒有鎖失效機制，由於有可能出現成功插入數據後，服務器宕機了，對應的數據沒有被刪除，當服務恢復後一直獲取不到鎖，因此，須要在表中新增一列，用於記錄失效時間，而且須要有定時任務清除這些失效的數據；

4. 不具有阻塞鎖特性，獲取不到鎖直接返回失敗，因此須要優化獲取邏輯，循環屢次去獲取。

5. 在實施的過程當中會遇到各類不一樣的問題，爲了解決這些問題，實現方式將會愈來愈複雜；依賴數據庫須要必定的資源開銷，性能問題須要考慮。

基於Redis實現分佈式鎖

1. 選用Redis實現分佈式鎖緣由：

• Redis有很高的性能；
• Redis命令對此支持較好，實現起來比較方便

2. 使用命令介紹：

• SETNX

SETNX key val：當且僅當key不存在時，set一個key爲val的字符串，返回1；若key存在，則什麼都不作，返回0。

• expire

expire key timeout：爲key設置一個超時時間，單位爲second，超過這個時間鎖會自動釋放，避免死鎖。

• delete

delete key：刪除key

在使用Redis實現分佈式鎖的時候，主要就會使用到這三個命令。

3. 實現思想：

• 獲取鎖的時候，使用setnx加鎖，並使用expire命令爲鎖添加一個超時時間，超過該時間則自動釋放鎖，鎖的value值爲一個隨機生成的UUID，經過此在釋放鎖的時候進行判斷。
• 獲取鎖的時候還設置一個獲取的超時時間，若超過這個時間則放棄獲取鎖。
• 釋放鎖的時候，經過UUID判斷是否是該鎖，如果該鎖，則執行delete進行鎖釋放。

基於Zookeeper實現分佈式鎖

ZooKeeper是一個爲分佈式應用提供一致性服務的開源組件，它內部是一個分層的文件系統目錄樹結構，規定同一個目錄下只能有一個惟一文件名。基於ZooKeeper實現分佈式鎖的步驟以下：

（1）建立一個目錄mylock；
（2）線程A想獲取鎖就在mylock目錄下建立臨時順序節點；
（3）獲取mylock目錄下全部的子節點，而後獲取比本身小的兄弟節點，若是不存在，則說明當前線程順序號最小，得到鎖；
（4）線程B獲取全部節點，判斷本身不是最小節點，設置監聽比本身次小的節點；
（5）線程A處理完，刪除本身的節點，線程B監聽到變動事件，判斷本身是否是最小的節點，若是是則得到鎖。

這裏推薦一個Apache的開源庫Curator，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分佈式鎖的實現，acquire方法用於獲取鎖，release方法用於釋放鎖。

優勢：具有高可用、可重入、阻塞鎖特性，可解決失效死鎖問題。

缺點：由於須要頻繁的建立和刪除節點，性能上不如Redis方式。

結語

歡迎關注微信公衆號『碼仔zonE』，專一於分享Java、雲計算相關內容，包括SpringBoot、SpringCloud、微服務、Docker、Kubernetes、Python等領域相關技術乾貨，期待與您相遇！