前言
- 分布式鎖需五，是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式
- 在分布式系統(tǒng)中，常常需要協(xié)調(diào)他們的動作。如果不同的系統(tǒng)或是同一個系統(tǒng)的不同主機之間共享了一個或一組資源，那么訪問這些資源的時候酷誓，往往需要互斥來防止彼此干擾來保證一致性披坏，在這種情況下态坦，便需要使用到分布式鎖。
- 這里主要簡單介紹三種方式：基于數(shù)據(jù)庫實現(xiàn)方式棒拂、基于redis實現(xiàn)方式伞梯、基于ZooKeeper實現(xiàn)方式。
場景舉例
- 假設有一個進程A帚屉，每小時準點給用戶發(fā)送一條短信"Hello world"谜诫，為了高可用，就必須在多臺機器上面部署多個進程攻旦，避免宕機的情況喻旷；
- 假設部署在兩臺機器，那么問題來了牢屋，用戶每個小時就會收到兩條"Hello world"且预，信息就重復了；
我們希望只發(fā)送一條"Hello world"烙无，那么就可以引入分布式鎖的概念3. 了锋谐； - 進程A和進程B發(fā)送短信前先去注冊一個鎖，假設進程A搶到了鎖截酷，進程B就等待結果涮拗，如果發(fā)送成功了，那么B就放棄此次任務迂苛，等待下一個小時三热。
- 問題的核心就在于怎么注冊鎖，檢查鎖的存在和注冊鎖是一個原子性操作三幻，類似mysql的主鍵康铭，存在則不能insert，就是說你不能把我的鎖覆蓋了赌髓，你得等著从藤；
- 我們有多種方式可以實現(xiàn)分布式鎖，最簡單的就是以每小時準點這個時間作為主鍵锁蠕，到mysql寫入一條數(shù)據(jù)夷野，利用數(shù)據(jù)庫來維持一致性。
為什么要使用分布式鎖
- 我們在開發(fā)應用的時候荣倾，如果需要對某一個共享變量進行多線程同步訪問的時候悯搔，可以使用我們學到的java多線程解決。
- 注意這是單機應用舌仍，也就是所有的請求都會分配到當前服務器的jvm內(nèi)部妒貌，然后映射為操作系統(tǒng)的線程進行處理通危，而這個共享變量只是在這個jvm內(nèi)部的一塊內(nèi)存空間。
- 后來業(yè)務發(fā)展灌曙，需要做集群菊碟，一個應用需要部署到幾臺機器上然后做負載均衡，大致如下圖：
- 上圖分析：
- 變量A存在JVM1在刺、JVM2逆害、JVM3三個JVM內(nèi)存中（這個變量A主要體現(xiàn)是在一個類中的一個成員變量，是一個有狀態(tài)的對象）蚣驼，如果不加任何控制的話魄幕，變量A同時都會在JVM1、JVM2颖杏、JVM3中分配一塊內(nèi)存纯陨；
- 三個請求發(fā)過來同時對這個變量進行操作，顯然結果是不同的留储。
- 即使不是同時發(fā)過來翼抠，三個請求分別操作三個不同JVM內(nèi)存區(qū)域的數(shù)據(jù)，變量A之間不存在共享欲鹏，也不具有可見性机久，處理的結果也是不對的。
- 如果我們業(yè)務中存在這種場景的話赔嚎，我們就需要一種方法解決這個問題膘盖。
為了保證一個方法或者屬性在高并發(fā)情況下的同一時間只能被同一個線程執(zhí)行，在傳統(tǒng)單機應用單機部署的情況下尤误，可以使用java并發(fā)處理的相關API進行互斥控制（如ReentrantLock或Synchronized）阻课。
在單機環(huán)境中席吴，java中提供了很多并發(fā)處理相關的API。
但是隨著業(yè)務發(fā)展的需要，原單體單機部署的系統(tǒng)被演化成分布式集群系統(tǒng)后县貌，由于分布式系統(tǒng)多線程涵卵、多進程并且分布在不同機器上侮措，這將使原單機部署情況下的并發(fā)控制鎖策略失效规伐，單純的java API并不能提供分布式鎖的能力。
為了解決這個問題最冰，就需要一種跨JVM的互斥機制來控制共享資源的訪問瘦棋，這就是分布式鎖要解決的問題。
分布式鎖應該具備的條件
- 在分布式系統(tǒng)環(huán)境下暖哨，一個方法在同一時間只能被一個機器的的一個線程執(zhí)行赌朋；
- 高可用的獲取鎖與釋放鎖；
- 高性能的獲取鎖與釋放鎖；
- 具備可重入特性沛慢；
- 具備鎖失效機制赡若，防止死鎖；
- 具備非阻塞鎖特性团甲，即沒有獲取到鎖將直接返回獲取鎖失敗逾冬。
分布式鎖實現(xiàn)方式-前言
- 目前幾乎很多大型網(wǎng)站及應用都是分布式部署的，分布式場景中的數(shù)據(jù)一致性問題一直是一個比較重要的話題伐庭。
- 分布式的CAP理論告訴我們粉渠，任何一個分布式系統(tǒng)都無法同時滿足一致性分冈、可用性圾另、和分區(qū)容錯性，最多只能同時滿足兩項雕沉。
- 所以集乔，很多系統(tǒng)在設計之初就對這三項做了取舍。在互聯(lián)網(wǎng)領域的絕大多數(shù)的場景中坡椒，都需要犧牲強一致性來換取系統(tǒng)的高可用性扰路，系統(tǒng)往往只需要保證最終一致性，只要這個最終時間實在用戶可以接受的范圍內(nèi)即可倔叼。
- 在很多場景中汗唱，我們?yōu)槔ＷC數(shù)據(jù)的最終一致性，需要很多的技術方案來支持丈攒，比如分布式事務哩罪、分布式鎖等，有時候我們需要保證一個方法在同一個線程執(zhí)行巡验。
- 基于數(shù)據(jù)庫實現(xiàn)分布式鎖际插；基于緩存redis等實現(xiàn)分布式鎖；基于Zookeeper實現(xiàn)分布式鎖显设。
基于數(shù)據(jù)庫的實現(xiàn)方式
- 基于數(shù)據(jù)庫的實現(xiàn)方式核心思想：在數(shù)據(jù)庫中創(chuàng)建一個表框弛，表中包含方法名等字段，并在方法名字段上創(chuàng)建唯一索引捕捂，想要執(zhí)行某個方法瑟枫，就使用這個方法名向表中插入數(shù)據(jù)，成功插入則獲取鎖指攒，執(zhí)行完成后刪除對應的行數(shù)據(jù)釋放鎖慷妙。
- 創(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=‘鎖定中的方法';
- 想要執(zhí)行某個方法，就使用這個方法名向表中插入數(shù)據(jù)：
INSERT INTO method_lock (method_name, desc) VALUES ('methodName', ‘測試的methodName');
- 因為我們對method_name做了唯一約束幽七，這里如果有多個請求同時提交到數(shù)據(jù)庫的話景殷，數(shù)據(jù)庫會保證只有一個操作可以成功，那么我們就可以認為操作成功的那個線程獲得了該方法的鎖，可以執(zhí)行方法體內(nèi)容猿挚。
- 成功插入則獲取鎖咐旧，執(zhí)行完成后刪除對應的行數(shù)據(jù)釋放鎖：
delete from method_lock where method_name ='methodName';
- 使用基于數(shù)據(jù)庫的這種實現(xiàn)方式很簡單，但是對于分布式鎖應該具備的條件來說绩蜻，它有一些問題需要解決及優(yōu)化：
- 因為是基于數(shù)據(jù)庫實現(xiàn)的铣墨，數(shù)據(jù)庫的可用性和性能將直接影響分布式鎖的可用性及性能，所以办绝，數(shù)據(jù)庫需要雙機部署伊约、數(shù)據(jù)同步、主備切換孕蝉。
- 不具備可重入的特性屡律，因為同一個線程在釋放鎖之前，行數(shù)據(jù)一直存在降淮，無法再次成功插入數(shù)據(jù)超埋，所以，需要在表中新增一列佳鳖，用于記錄當前獲取到鎖的機器和線程信息霍殴，在再次獲取鎖的時候，先查詢表中機器和線程信息是否和當前機器和線程信息相同系吩，若相同則直接獲取鎖来庭；
- 沒有鎖失效機制，因為有可能出現(xiàn)成功插入數(shù)據(jù)后穿挨，服務器宕機了月弛，對應的數(shù)據(jù)沒有被刪除，當服務恢復后一直獲取不到鎖絮蒿，所以尊搬，需要在鎖中新增一列，用于記錄失效時間土涝，并且需要有定時任務清除這些失效的數(shù)據(jù)佛寿；
- 不具備阻塞鎖特性，獲取不到鎖直接返回失敗但壮，所以需要優(yōu)化獲取邏輯冀泻，循環(huán)多次去獲取。
- 在實施過程中會遇到各種不同問題蜡饵，為了解決這些問題弹渔，實現(xiàn)方式將會越來越復雜；依賴數(shù)據(jù)庫需要一定的資源開銷溯祸，性能問題需要考慮肢专。
基于redis的實現(xiàn)方式
- 選擇redis分布式鎖的原因：
- redis有很高的性能舞肆；
- redis對此支持的命令較好，實現(xiàn)起來比較方便
- 使用分布式鎖的時候主要用到的命令介紹：
- SETNX
SETNX key val：當且僅當key不存在時博杖，set一個key為val的字符串椿胯，返回1；若key存在剃根，則什么都不做哩盲，返回0。- expire
expire key timeout：當key設置一個超時時間狈醉，單位為second廉油，超過這個時間鎖會自動釋放，避免死鎖苗傅。- delete
delete key：刪除key
- 實現(xiàn)思想：
- 獲取鎖的時候抒线，使用setnx加鎖，并使用expire命令給鎖加一個超時時間金吗，超過該時間則自動釋放鎖十兢，鎖的value值為一個隨機生成的UUID趣竣，通過此在釋放鎖的時候進行判斷摇庙。
- 獲取鎖的時候還設置一個獲取的超時時間，若超過這個時間則放棄獲取鎖遥缕。
- 釋放鎖的時候卫袒，通過UUID判斷是不是該鎖，若是該鎖单匣，則執(zhí)行delete進行鎖釋放夕凝。
基于ZooKeeper的實現(xiàn)方式
- ZooKeeper是一個為分布式應用提供一致性服務的開源組件，它內(nèi)部是一個分層的文件系統(tǒng)目錄樹結構户秤，規(guī)定同一個目錄下只能有一個唯一文件名码秉。
- 基于ZooKeeper實現(xiàn)分布式鎖的步驟如下：
- 創(chuàng)建一個目錄mylock；
- 線程A想獲取鎖就在mylock目錄下創(chuàng)建臨時順序節(jié)點鸡号；
- 獲取mylock目錄下所有的子節(jié)點转砖，然后獲取比自己小的兄弟節(jié)點，如果不存在鲸伴，則說明當前線程順序號最小府蔗，獲得鎖；
- 線程B獲取所有節(jié)點汞窗，判斷自己不是最小節(jié)點姓赤，設置監(jiān)聽比自己小的節(jié)點；
- 線程A處理完仲吏，刪除自己的節(jié)點不铆，線程B監(jiān)聽到變更事件蝌焚，判斷自己是不是最小節(jié)點，如果是則獲得鎖誓斥。
- 這里推薦一個Apache的開源庫Curator综看，它是一個ZooKeeper客戶端，Curator提供的InterProcessMutex是分布式鎖的實現(xiàn)岖食，acquire方法用于獲取鎖红碑，release用于釋放鎖。
- 優(yōu)點：具備高可用泡垃、可重入析珊、阻塞鎖特性，可解決失效死鎖問題蔑穴。
- 缺點：因為需要頻繁的創(chuàng)建和刪除節(jié)點忠寻，性能上不如redis方式。
總結
- 上面的三種方式存和，沒有在所有場合都是完美的奕剃，所以，應根據(jù)不同的應用場景選擇最適合的實現(xiàn)方式捐腿。
- 分布式環(huán)境中纵朋，對資源進行上鎖有時候是很重要的，比如搶購某一資源茄袖，這時候使用分布式鎖就可以很好的控制資源操软。
寫在最后
點關注，不迷路宪祥；【Java_蘇先生】持續(xù)更新Java相關技術及咨詢文章
