分布式鎖機(jī)制原理及實(shí)現(xiàn)方式

前言

  1. 分布式鎖，是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式
  2. 在分布式系統(tǒng)中，常常需要協(xié)調(diào)他們的動作。如果不同的系統(tǒng)或是同一個系統(tǒng)的不同主機(jī)之間共享了一個或一組資源，那么訪問這些資源的時候，往往需要互斥來防止彼此干擾來保證一致性，在這種情況下，便需要使用到分布式鎖。
  3. 這里主要簡單介紹三種方式：基于數(shù)據(jù)庫實(shí)現(xiàn)方式、基于redis實(shí)現(xiàn)方式、基于ZooKeeper實(shí)現(xiàn)方式。

場景舉例

  1. 假設(shè)有一個進(jìn)程A，每小時準(zhǔn)點(diǎn)給用戶發(fā)送一條短信"Hello world"，為了高可用，就必須在多臺機(jī)器上面部署多個進(jìn)程，避免宕機(jī)的情況；
  2. 假設(shè)部署在兩臺機(jī)器，那么問題來了，用戶每個小時就會收到兩條"Hello world"，信息就重復(fù)了；
    我們希望只發(fā)送一條"Hello world"，那么就可以引入分布式鎖的概念3. 了；
  3. 進(jìn)程A和進(jìn)程B發(fā)送短信前先去注冊一個鎖，假設(shè)進(jìn)程A搶到了鎖，進(jìn)程B就等待結(jié)果，如果發(fā)送成功了，那么B就放棄此次任務(wù)，等待下一個小時。
  4. 問題的核心就在于怎么注冊鎖，檢查鎖的存在和注冊鎖是一個原子性操作，類似mysql的主鍵，存在則不能insert，就是說你不能把我的鎖覆蓋了，你得等著；
  5. 我們有多種方式可以實(shí)現(xiàn)分布式鎖，最簡單的就是以每小時準(zhǔn)點(diǎn)這個時間作為主鍵，到mysql寫入一條數(shù)據(jù)，利用數(shù)據(jù)庫來維持一致性。

為什么要使用分布式鎖

  1. 我們在開發(fā)應(yīng)用的時候，如果需要對某一個共享變量進(jìn)行多線程同步訪問的時候，可以使用我們學(xué)到的java多線程解決。
  2. 注意這是單機(jī)應(yīng)用，也就是所有的請求都會分配到當(dāng)前服務(wù)器的jvm內(nèi)部，然后映射為操作系統(tǒng)的線程進(jìn)行處理，而這個共享變量只是在這個jvm內(nèi)部的一塊內(nèi)存空間。
  3. 后來業(yè)務(wù)發(fā)展，需要做集群，一個應(yīng)用需要部署到幾臺機(jī)器上然后做負(fù)載均衡，大致如下圖：
  1. 上圖分析：
  • 變量A存在JVM1、JVM2、JVM3三個JVM內(nèi)存中（這個變量A主要體現(xiàn)是在一個類中的一個成員變量，是一個有狀態(tài)的對象），如果不加任何控制的話，變量A同時都會在JVM1、JVM2、JVM3中分配一塊內(nèi)存；
  • 三個請求發(fā)過來同時對這個變量進(jìn)行操作，顯然結(jié)果是不同的。
  • 即使不是同時發(fā)過來，三個請求分別操作三個不同JVM內(nèi)存區(qū)域的數(shù)據(jù)，變量A之間不存在共享，也不具有可見性，處理的結(jié)果也是不對的。
  • 如果我們業(yè)務(wù)中存在這種場景的話，我們就需要一種方法解決這個問題。

  1. 為了保證一個方法或者屬性在高并發(fā)情況下的同一時間只能被同一個線程執(zhí)行，在傳統(tǒng)單機(jī)應(yīng)用單機(jī)部署的情況下，可以使用java并發(fā)處理的相關(guān)API進(jìn)行互斥控制（如ReentrantLock或Synchronized）。

  2. 在單機(jī)環(huán)境中，java中提供了很多并發(fā)處理相關(guān)的API。

  3. 但是隨著業(yè)務(wù)發(fā)展的需要，原單體單機(jī)部署的系統(tǒng)被演化成分布式集群系統(tǒng)后，由于分布式系統(tǒng)多線程、多進(jìn)程并且分布在不同機(jī)器上，這將使原單機(jī)部署情況下的并發(fā)控制鎖策略失效，單純的java API并不能提供分布式鎖的能力。

  4. 為了解決這個問題，就需要一種跨JVM的互斥機(jī)制來控制共享資源的訪問，這就是分布式鎖要解決的問題。

分布式鎖應(yīng)該具備的條件

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

分布式鎖實(shí)現(xiàn)方式-前言

  1. 目前幾乎很多大型網(wǎng)站及應(yīng)用都是分布式部署的，分布式場景中的數(shù)據(jù)一致性問題一直是一個比較重要的話題。
  2. 分布式的CAP理論告訴我們，任何一個分布式系統(tǒng)都無法同時滿足一致性、可用性、和分區(qū)容錯性，最多只能同時滿足兩項(xiàng)。
  3. 所以，很多系統(tǒng)在設(shè)計(jì)之初就對這三項(xiàng)做了取舍。在互聯(lián)網(wǎng)領(lǐng)域的絕大多數(shù)的場景中，都需要犧牲強(qiáng)一致性來換取系統(tǒng)的高可用性，系統(tǒng)往往只需要保證最終一致性，只要這個最終時間實(shí)在用戶可以接受的范圍內(nèi)即可。
  4. 在很多場景中，我們?yōu)槔ＷC數(shù)據(jù)的最終一致性，需要很多的技術(shù)方案來支持，比如分布式事務(wù)、分布式鎖等，有時候我們需要保證一個方法在同一個線程執(zhí)行。
  5. 基于數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖；基于緩存redis等實(shí)現(xiàn)分布式鎖；基于Zookeeper實(shí)現(xiàn)分布式鎖。

基于數(shù)據(jù)庫的實(shí)現(xiàn)方式

  1. 基于數(shù)據(jù)庫的實(shí)現(xiàn)方式核心思想：在數(shù)據(jù)庫中創(chuàng)建一個表，表中包含方法名等字段，并在方法名字段上創(chuàng)建唯一索引，想要執(zhí)行某個方法，就使用這個方法名向表中插入數(shù)據(jù)，成功插入則獲取鎖，執(zhí)行完成后刪除對應(yīng)的行數(shù)據(jù)釋放鎖。
  2. 創(chuàng)建一個表：
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=‘鎖定中的方法';
  1. 想要執(zhí)行某個方法，就使用這個方法名向表中插入數(shù)據(jù)：
INSERT INTO method_lock (method_name, desc) VALUES ('methodName', ‘測試的methodName');
  1. 因?yàn)槲覀儗ethod_name做了唯一約束，這里如果有多個請求同時提交到數(shù)據(jù)庫的話，數(shù)據(jù)庫會保證只有一個操作可以成功，那么我們就可以認(rèn)為操作成功的那個線程獲得了該方法的鎖，可以執(zhí)行方法體內(nèi)容。
  2. 成功插入則獲取鎖，執(zhí)行完成后刪除對應(yīng)的行數(shù)據(jù)釋放鎖：
delete from method_lock where method_name ='methodName';
  1. 使用基于數(shù)據(jù)庫的這種實(shí)現(xiàn)方式很簡單，但是對于分布式鎖應(yīng)該具備的條件來說，它有一些問題需要解決及優(yōu)化：
  • 因?yàn)槭腔跀?shù)據(jù)庫實(shí)現(xiàn)的，數(shù)據(jù)庫的可用性和性能將直接影響分布式鎖的可用性及性能，所以，數(shù)據(jù)庫需要雙機(jī)部署、數(shù)據(jù)同步、主備切換。
  • 不具備可重入的特性，因?yàn)橥粋€線程在釋放鎖之前，行數(shù)據(jù)一直存在，無法再次成功插入數(shù)據(jù)，所以，需要在表中新增一列，用于記錄當(dāng)前獲取到鎖的機(jī)器和線程信息，在再次獲取鎖的時候，先查詢表中機(jī)器和線程信息是否和當(dāng)前機(jī)器和線程信息相同，若相同則直接獲取鎖；
  • 沒有鎖失效機(jī)制，因?yàn)橛锌赡艹霈F(xiàn)成功插入數(shù)據(jù)后，服務(wù)器宕機(jī)了，對應(yīng)的數(shù)據(jù)沒有被刪除，當(dāng)服務(wù)恢復(fù)后一直獲取不到鎖，所以，需要在鎖中新增一列，用于記錄失效時間，并且需要有定時任務(wù)清除這些失效的數(shù)據(jù)；
  • 不具備阻塞鎖特性，獲取不到鎖直接返回失敗，所以需要優(yōu)化獲取邏輯，循環(huán)多次去獲取。
  1. 在實(shí)施過程中會遇到各種不同問題，為了解決這些問題，實(shí)現(xiàn)方式將會越來越復(fù)雜；依賴數(shù)據(jù)庫需要一定的資源開銷，性能問題需要考慮。

基于redis的實(shí)現(xiàn)方式

  1. 選擇redis分布式鎖的原因：
  • redis有很高的性能；
  • redis對此支持的命令較好，實(shí)現(xiàn)起來比較方便
  1. 使用分布式鎖的時候主要用到的命令介紹：
  • SETNX
    SETNX key val：當(dāng)且僅當(dāng)key不存在時，set一個key為val的字符串，返回1；若key存在，則什么都不做，返回0。
  • expire
    expire key timeout：當(dāng)key設(shè)置一個超時時間，單位為second，超過這個時間鎖會自動釋放，避免死鎖。
  • delete
    delete key：刪除key
  1. 實(shí)現(xiàn)思想：
  • 獲取鎖的時候，使用setnx加鎖，并使用expire命令給鎖加一個超時時間，超過該時間則自動釋放鎖，鎖的value值為一個隨機(jī)生成的UUID，通過此在釋放鎖的時候進(jìn)行判斷。
  • 獲取鎖的時候還設(shè)置一個獲取的超時時間，若超過這個時間則放棄獲取鎖。
  • 釋放鎖的時候，通過UUID判斷是不是該鎖，若是該鎖，則執(zhí)行delete進(jìn)行鎖釋放。

基于ZooKeeper的實(shí)現(xiàn)方式

  1. ZooKeeper是一個為分布式應(yīng)用提供一致性服務(wù)的開源組件，它內(nèi)部是一個分層的文件系統(tǒng)目錄樹結(jié)構(gòu)，規(guī)定同一個目錄下只能有一個唯一文件名。
  2. 基于ZooKeeper實(shí)現(xiàn)分布式鎖的步驟如下：
  • 創(chuàng)建一個目錄mylock；
  • 線程A想獲取鎖就在mylock目錄下創(chuàng)建臨時順序節(jié)點(diǎn)；
  • 獲取mylock目錄下所有的子節(jié)點(diǎn)，然后獲取比自己小的兄弟節(jié)點(diǎn)，如果不存在，則說明當(dāng)前線程順序號最小，獲得鎖；
  • 線程B獲取所有節(jié)點(diǎn)，判斷自己不是最小節(jié)點(diǎn)，設(shè)置監(jiān)聽比自己小的節(jié)點(diǎn)；
  • 線程A處理完，刪除自己的節(jié)點(diǎn)，線程B監(jiān)聽到變更事件，判斷自己是不是最小節(jié)點(diǎn)，如果是則獲得鎖。
  1. 這里推薦一個Apache的開源庫Curator，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實(shí)現(xiàn)，acquire方法用于獲取鎖，release用于釋放鎖。
  2. 優(yōu)點(diǎn)：具備高可用、可重入、阻塞鎖特性，可解決失效死鎖問題。
  3. 缺點(diǎn)：因?yàn)樾枰l繁的創(chuàng)建和刪除節(jié)點(diǎn)，性能上不如redis方式。

總結(jié)

  1. 上面的三種方式，沒有在所有場合都是完美的，所以，應(yīng)根據(jù)不同的應(yīng)用場景選擇最適合的實(shí)現(xiàn)方式。
  2. 分布式環(huán)境中，對資源進(jìn)行上鎖有時候是很重要的，比如搶購某一資源，這時候使用分布式鎖就可以很好的控制資源。

寫在最后

點(diǎn)關(guān)注，不迷路；【Java_蘇先生】持續(xù)更新Java相關(guān)技術(shù)及咨詢文章

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容