[發明專利]分布式鎖實現方法、系統、設備及存儲介質

在審

• 申請號: 201811468636.3
• 申請日: 2018-12-03
• 公開（公告）號: CN111258976A
• 公開（公告）日: 2020-06-09
• 發明（設計）人: 安金龍;劉業輝;張飛;張寧;高相斌;王彥明
• 申請（專利權）人: 北京京東尚科信息技術有限公司;北京京東世紀貿易有限公司
• 主分類號: G06F16/182
• 分類號: G06F16/182;G06F16/176
• 代理公司: 北京律智知識產權代理有限公司 11438
• 代理人: 袁禮君;闞梓瑄

本發明提供了一種分布式鎖實現方法、系統、設備及存儲介質，該方法包括以下步驟：創建多個鎖文件，將各個鎖文件分別存儲至分布式文件系統的各個目標路徑，各個鎖文件包括鎖狀態信息；接收鎖申請請求，將請求者信息寫入請求的目標鎖對應的鎖狀態信息，鎖申請請求包括請求者信息；判斷目標鎖的鎖狀態信息與請求者信息是否一致；如果一致，則確定請求者獲取目標鎖成功；如果不一致，則確定請求者獲取目標鎖失敗。本發明通過布式文件系統實現了一種大數據場景下的簡單高效的分布式鎖，從而實現在多并發場景下對共享資源的互斥操作；同時，本發明無需引入其他存儲或者服務，降低了系統復雜度，降低了開發成本。

技術領域

本發明涉及物流領域，具體地說，涉及一種基于HDFS文件系統的分布式鎖實現方法、系統、設備及存儲介質。

背景技術

隨著大數據時代的到來，hadoop框架已經成為大數據領域的基礎架構，使用hadoop來進行大數據處理已經成為非常便捷、普及的事情。Hadoop主要由計算模塊MapReduce和分布式文件存儲模塊(Hadoop Distributed File System，HDFS)組成，使用HDFS進行文件存儲已經成為非常成熟和通用的技術，但是在大數據場景下對共享資源的互斥訪問依然存在問題。與此同時在互聯網環境中，幾乎所有大型網站及應用都是分布式部署的，分布式場景中的數據一致性問題一直是一個比較重要的話題。分布式的CAP理論告訴我們“任何一個分布式系統都無法同時滿足一致性(Consistency)、可用性(Availability)和分區容錯性(Partition tolerance)，最多只能同時滿足兩項。”所以，很多系統在設計之初就要對這三者做出取舍。在大數據和互聯網領域的絕大多數的場景中，都需要犧牲強一致性來換取系統的高可用性，系統往往只需要保證“最終一致性”，只要這個最終時間是在用戶可以接受的范圍內即可。在分布式系統中，共享資源互斥訪問問題非常普遍，而針對訪問共享資源的互斥問題，常用的解決方案就是使用分布式鎖。

在很多場景中，為了保證數據的最終一致性，需要很多的技術方案來支持，比如分布式事務、分布式鎖等。有時需要保證一個方法在同一時間內只能被同一個線程執行。在單機環境中，Java中其實提供了很多并發處理相關的API，但是這些API在分布式場景中就無能為力了，也就是說單純的Java API并不能提供分布式鎖的能力。所以針對分布式鎖的實現目前有多種方案。針對分布式鎖的實現，目前比較常用的有以下幾種方案：基于數據庫(mysql)實現分布式鎖、基于緩存(redis，memcached，tair)實現分布式鎖、基于Zookeeper實現分布式鎖。

其中，基于數據庫表實現分布式鎖，要實現分布式鎖，最簡單的方式可能就是直接創建一張鎖表，然后通過操作該表中的數據來實現了。當要鎖住某個方法或資源時，就在該表中增加一條記錄，想要釋放鎖的時候就刪除這條記錄。

創建這樣一張數據庫表methodLock,包含4個字段：id(主鍵)、method_name(鎖定的方法名)、desc(備注信息)和update_time(更新時間)。當想要鎖住某個方法時，執行以下SQL：

insert into methodLock(method_name,desc)values(‘method_name’,‘desc’)

因為對method_name做了唯一性約束，如果有多個請求同時提交到數據庫的話，數據庫會保證只有一個操作可以成功，那么就可以認為操作成功的那個線程獲得了該方法的鎖，可以執行方法體內容。當方法執行完畢之后，想要釋放鎖的話，需要執行以下Sq：

delete from methodLock where method_name＝'method_name'

基于數據庫表實現分布式鎖這種簡單的實現有以下幾個問題：

a.這把鎖強依賴數據庫的可用性，數據庫是一個單點，一旦數據庫掛掉，會導致業務系統不可用；