2. 程式人生 > 其它 >3. 分散式鎖

3. 分散式鎖

阿新 • • 發佈：2021-09-13

Java中的鎖 可以簡單的理解為多執行緒情況下訪問臨界資源的一種執行緒同步機制

為什麼要使用分散式鎖

我們在開發應用的時候，如果需要對某一個共享變數進行多執行緒同步訪問的時候，可以使用我們學到的Java多執行緒的18般武藝進行處理，並且可以完美的執行，毫無Bug！ 注意這是單機應用，也就是所有的請求都會分配到當前伺服器的JVM內部，然後對映為作業系統的執行緒進行處理！而這個共享變數只是在這個JVM內部的一塊記憶體空間！ 後來業務發展，需要做叢集，一個應用需要部署到幾臺機器上然後做負載均衡, 大致如下圖： 上圖可以看到，變數A存在JVM1、JVM2、JVM3三個JVM記憶體中（這個變數A主要體現是在一個類中的一個成員變數，是一個有狀態的物件，例如：UserController控制器中的一個整形型別的成員變數），如果不加任何控制的話，變數A同時都會在JVM分配一塊記憶體，三個請求發過來同時對這個變數操作，顯然結果是不對的！即使不是同時發過來，三個請求分別操作三個不同JVM記憶體區域的資料，變數A之間不存在共享，也不具有可見性，處理的結果也是不對的！
 為了保證一個方法或屬性在高併發情況下的同一時間只能被同一個執行緒執行，在傳統單體應用單機部署的情況下，可以使用Java併發處理相關的API(如ReentrantLock或Synchronized)進行互斥控制。 但是，隨著業務發展的需要，原單體單機部署的系統被演化成分散式集群系統後，由於分散式系統多執行緒、多程序並且分佈在不同機器上，這將使原單機部署情況下的併發控制鎖策略失效，單純的Java API並不能提供分散式鎖的能力。為了解決這個問題就需要一種跨JVM的互斥機制來控制共享資源的訪問，這就是分散式鎖要解決的問題！

分散式鎖應該具備哪些條件

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

分散式鎖的三種實現方式

在很多場景中，我們為了保證資料的最終一致性，需要很多的技術方案來支援，比如分散式事務、分散式鎖等。有的時候，我們需要保證一個方法在同一時間內只能被同一個執行緒執行。 基於資料庫實現分散式鎖； 基於快取（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'); 1 因為我們對method_name做了唯一性約束，這裡如果有多個請求同時提交到資料庫的話，資料庫會保證只有一個操作可以成功，那麼我們就可以認為操作成功的那個執行緒獲得了該方法的鎖，可以執行方法體內容。 （3）成功插入則獲取鎖，執行完成後刪除對應的行資料釋放鎖： delete from method_lock where method_name ='methodName'; 1 注意：這只是使用基於資料庫的一種方法，使用資料庫實現分散式鎖還有很多其他的玩法！ 使用基於資料庫的這種實現方式很簡單，但是對於分散式鎖應該具備的條件來說，它有一些問題需要解決及優化： 1、因為是基於資料庫實現的，資料庫的可用性和效能將直接影響分散式鎖的可用性及效能，所以，資料庫需要雙機部署、資料同步、主備切換； 2、不具備可重入的特性，因為同一個執行緒在釋放鎖之前，行資料一直存在，無法再次成功插入資料，所以，需要在表中新增一列，用於記錄當前獲取到鎖的機器和執行緒資訊，在再次獲取鎖的時候，先查詢表中機器和執行緒資訊是否和當前機器和執行緒相同，若相同則直接獲取鎖； 3、沒有鎖失效機制，因為有可能出現成功插入資料後，伺服器宕機了，對應的資料沒有被刪除，當服務恢復後一直獲取不到鎖，所以，需要在表中新增一列，用於記錄失效時間，並且需要有定時任務清除這些失效的資料； 4、不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優化獲取邏輯，迴圈多次去獲取。 5、在實施的過程中會遇到各種不同的問題，為了解決這些問題，實現方式將會越來越複雜；依賴資料庫需要一定的資源開銷，效能問題需要考慮。

五、基於Redis的實現方式

1、選用Redis實現分散式鎖原因： （1）Redis有很高的效能； （2）Redis命令對此支援較好，實現起來比較方便 2、使用命令介紹： （1）SETNX SETNX key val：當且僅當key不存在時，set一個key為val的字串，返回1；若key存在，則什麼都不做，返回0。 1 （2）expire expire key timeout：為key設定一個超時時間，單位為second，超過這個時間鎖會自動釋放，避免死鎖。 1 （3）delete delete key：刪除key 1 在使用Redis實現分散式鎖的時候，主要就會使用到這三個命令。

3、實現思想： （1）獲取鎖的時候，使用setnx加鎖，並使用expire命令為鎖新增一個超時時間，超過該時間則自動釋放鎖，鎖的value值為一個隨機生成的UUID，通過此在釋放鎖的時候進行判斷。 （2）獲取鎖的時候還設定一個獲取的超時時間，若超過這個時間則放棄獲取鎖。 （3）釋放鎖的時候，通過UUID判斷是不是該鎖，若是該鎖，則執行delete進行鎖釋放。 4、 分散式鎖的簡單實現程式碼： https://xuliugen.blog.csdn.net/article/details/79036337?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-10.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-10.control
 5、測試剛才實現的分散式鎖 使用50個執行緒模擬秒殺一個商品

5、基於ZooKeeper的實現方式

ooKeeper是一個為分散式應用提供一致性服務的開源元件，它內部是一個分層的檔案系統目錄樹結構，規定同一個目錄下只能有一個唯一檔名。基於ZooKeeper實現分散式鎖的步驟如下： （1）建立一個目錄mylock； （2）執行緒A想獲取鎖就在mylock目錄下建立臨時順序節點； （3）獲取mylock目錄下所有的子節點，然後獲取比自己小的兄弟節點，如果不存在，則說明當前執行緒順序號最小，獲得鎖； （4）執行緒B獲取所有節點，判斷自己不是最小節點，設定監聽比自己次小的節點； （5）執行緒A處理完，刪除自己的節點，執行緒B監聽到變更事件，判斷自己是不是最小的節點，如果是則獲得鎖。 這裡推薦一個Apache的開源庫Curator，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分散式鎖的實現，acquire方法用於獲取鎖，release方法用於釋放鎖。 優點：具備高可用、可重入、阻塞鎖特性，可解決失效死鎖問題。 缺點：因為需要頻繁的建立和刪除節點，效能上不如Redis方式。

相關推薦

分散式鎖(3) —— 分散式鎖租約續期

Redis分散式鎖在加鎖的時候，我們一般都會給一個鎖的過期時間（TTL），這是為了防止加鎖後client宕機，鎖無法被釋放的問題。但是所有這種姿勢的用法都會面臨同一個問題，就是沒發保證client的執行時間一定小於鎖的TT

3. 分散式鎖

Java中的鎖 可以簡單的理解為多執行緒情況下訪問臨界資源的一種執行緒同步機制

Redis專題（3）：鎖的基本概念到Redis分散式鎖實現

拓展閱讀：Redis閒談（1）：構建知識圖譜 Redis專題(2)：Redis資料結構底層探祕 近來，分散式的問題被廣泛提及，比如分散式事務、分散式框架、ZooKeeper、SpringCloud等等。本文先回顧鎖的概念，再介紹分散式鎖，以及

ZooKeeper - 3 Curator分散式鎖使用樣例：模擬12306售票

ZooKeeper Curator分散式鎖 - 使用樣例：模擬12306售票 匯入座標 外掛 <dependency>

Redis 實現分散式鎖

在單節點情況下，實現執行緒安全需要靠同步狀態來控制。而在分散式應用中，使程式正確執行不被併發問題影響，就需要分散式鎖來控制。

SpringBoot + Redisson實現分散式鎖

一、什麼是分散式？ 要想說什麼是分散式，那麼首先要知道分散式之前的系統是什麼樣的架構，之前的架構又存在什麼樣的問題？

Node.js 中實踐基於 Redis 的分散式鎖實現

在一些分散式環境下、多執行緒併發程式設計中，如果對同一資源進行讀寫操作，避免不了的一個就是資源競爭問題，通過引入分散式鎖這一概念，可以解決資料一致性問題。

一篇文章帶你解讀redis分散式鎖的發展史和正確實現方式

來源：點我達技術 http://tech.dianwoda.com/ 前言 近兩年來微服務變得越來越熱門，越來越多的應用部署在分散式環境中，在分散式環境中，資料一致性是一直以來需要關注並且去解決的問題，分散式鎖也就成為了一種廣泛

分散式鎖的由來、特點、及Redis分散式鎖的實現詳解

什麼是分散式鎖 要介紹分散式鎖，首先要提到與分散式鎖相對應的是執行緒鎖、程式鎖。

聊聊分散式鎖的實現(一)

在併發程式設計中最常用的手段就是鎖了，比如基於JVM底層的synchronized、基於AQS的ReentrantLock；可是這些鎖都只是侷限於單機，本篇給大家介紹常見的分散式鎖。

redLock可靠的分散式鎖

本文是對 Martin Kleppmann 的文章 How to do distributed locking 部分內容的翻譯和總結，上次寫 Redlock 的原因就是看到了 Martin 的這篇文章，寫得很好，特此翻譯和總結。感興趣的同學可以翻看原文，相信會收穫良

聊聊分散式鎖的實現(二)

上一篇給大家介紹了基於redis的分散式鎖不知道有沒有給你解釋清楚，這次介紹一種基於zooKeeper的實現方式，本文只會介紹相關的zooKeeper知識，有興趣的同學可以自行學習。

SpringBoot 整合 redis 分散式鎖

繼上一篇 SpringBoot 整合 redis 踩坑日誌之後，又學習了 redis 分散式鎖，那為什麼需要分散式鎖？

SpringBoot 整合 Redisson 實現分散式鎖

上篇 《SpringBoot 整合 redis 分散式鎖優化》對死鎖的問題進行了優化，今天介紹的是 redis 官方推薦使用的 Redisson ，Redisson 架設在 redis 基礎上的 Java 駐記憶體資料網格（In-Memory Data Grid），基於NIO的 N

Redis分散式鎖（三）：支援鎖可重入，避免鎖遞迴呼叫時死鎖

使用現狀 Redis分散式鎖的基礎內容，我們已經在Redis分散式鎖：基於AOP和Redis實現的簡易版分散式鎖這篇文章中講過了，也在文章中示範了正常的加鎖和解鎖方法。

分散式鎖都有哪些實現方案？

一、業務場景 同一個jvm裡多個執行緒操作同一個有狀態的變數，可以通過JVM內的鎖保證執行緒安全。

Redis的複合SET命令和簡易的分散式鎖優化

前提 最近在跟進一個比較老的系統的時候，發現了所有排程任務使用了spring-context裡面的@Scheduled註解和自行基於Redis封裝的簡易分散式鎖控制任務不併發執行。為了不引入其他框架的情況下做一些簡單優化，筆者花點

redis分散式鎖原始碼分析

更多原始碼分析已釋出到https://github.com/Zhucola/php_frameworks_analysis 目錄 單機模式下的redis鎖

ZooKeeper分散式專題(七)-- 使用zookeeper實現分散式鎖

ZooKeeper分散式專題與Dubbo微服務入門 zookeeper實現分散式鎖 什麼多執行緒 多執行緒為了能夠提高應用程式的執行效率，在一個程式中有多條不同的執行路徑，同時並行執行，互不影響。

zookeeper分散式鎖

       在專案中，當共享資源出現競爭情況的時候，為了防止出現併發問題，我們一般會採用鎖機制來控制。在單機環境下，可以使用synchronized或Lock來實現；但是在分散式系統中，因為競爭的執行緒可能不在同一個節