文章主要給大家介紹了關於MySQL藉助DB實現分散式鎖思路的相關資料，文中通過示例程式碼介紹的非常詳細，對大家學習或者使用MySQL具有一定的參考學習價值，需要的朋友們下面來一起學習學習吧。
前言
無論是單機鎖還是分散式鎖，原理都是基於共享的資料，判斷當前操作的行為。對於單機則是共享RAM記憶體，對於叢集則可以藉助Redis，ZK，DB等第三方元件來實現。Redis，ZK對分散式鎖提供了很好的支援，基本上開箱即用，然而這些元件本身要高可用，系統也需要強依賴這些元件，額外增加了不少成本。DB對於系統來說本身就預設為高可用元件，針對一些低頻的業務使用DB實現分散式鎖也是一個不錯的解決方案，比如控制多機器下定時任務的起調，針對審批迴調處理等，本文將給出DB實現分散式鎖的一些場景以及解決方案，希望對你啟發。
表設計
首先要明確DB在系統中仍然需要認為是最脆弱的一環，因此在設計時需要考慮壓力問題，即能應用實現的邏輯就不要放到DB上實現，也就是儘量少使用DB提供的鎖能力，如果是高併發業務則要避免使用DB鎖，換成Redis等快取鎖更加有效。如清單1所示，該表中唯一的約束為lock_name,timestamp,version三者組合主鍵，下文會利用這三者實現悲觀鎖，樂觀鎖等業務場景。
清單1: 分散式鎖表結構
CREATE TABLE `lock` (
`lock_name` varchar(32) NOT NULL DEFAULT '' COMMENT '鎖名稱',
`resource` bigint(20) NOT NULL COMMENT '業務主鍵',
`version` int(5) NOT NULL COMMENT '版本',
`gmt_create` datetime NOT NULL COMMENT '生成時間',
PRIMARY KEY (`lock_name`,`resource`,`version`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
觀鎖實現
對於悲觀鎖業務中常見的操作有以下兩種：
針對A：
A場景當一臺機器獲取到鎖後，其他機器處於排隊狀態，鎖釋放後其他機器才能夠繼續下去，這種應用層面解決是相當麻煩，因此一般使用DB提供的行鎖能力，即select xxx from xxx for update。A場景一般都和業務強關聯，比如庫存增減，使用業務物件作為行鎖即可。需要注意的是，該方案本質上鎖壓力還是在資料庫上，當阻塞住的執行緒過多，且操作耗時，最後會出現大量鎖超時現象。
針對B：
針對B場景(tryLock)舉個具體業務，在叢集下每臺機器都有定時任務，但是業務上要求同一時刻只能有一臺能正常排程。
解決思路是利用唯一主鍵約束，插入一條針對TaskA的記錄，版本則預設為1，插入成功的算獲取到鎖，繼續執行業務操作。這種方案當機器掛掉就會出現死鎖，因此還需要有一個定時任務，定時清理已經過期的鎖，清理維度可以根據lock_name設定不同時間清理策略。
定時任務清理策略會額外帶來複雜度，假設機器A獲取到了鎖，但由於CPU資源緊張，導致處理變慢，此時鎖被定時任務釋放，因此機器B也會獲取到鎖，那麼此時就出現同一時刻兩臺機器同時持有鎖的現象，解決思路：把超時時間設定為遠大於業務處理時間，或者增加版本機制改成樂觀鎖。
insert into lock set lock_name='TaskA' , resource='鎖住的業務',version=1,gmt_create=now()
success: 獲取到鎖
failed：放棄操作
釋放鎖
樂觀鎖實現
針對樂觀鎖場景，舉個具體業務，在後臺系統中經常使用大json擴充套件欄位儲存業務屬性，在涉及部分更新時，需要先查詢出來，合併資料，寫入到DB，這個過程中如果存在併發，則很容易造成資料丟失，因此需要使用鎖來保證資料一致性，相應操作如下所示，針對樂觀鎖，不存在死鎖，因此這裡直接存放業務id欄位，保證每一個業務id有一條對應的記錄，並且不需要對應的定時器清除
。
select * from lock where lock_name='業務名稱', resource='業務id';
不存在: insert into lock set lock_name='業務名稱', resource='業務id' , version=1;
獲取版本: version
業務操作: 取資料，合併資料，寫回資料
寫回到DB: update lock set version=version+1 where lock_name='業務名稱' and resource='業務id' and version= #{version};
寫回成功: 操作成功
寫回失敗: 回滾事務，從頭操作
分散式鎖的原理實際上很容易理解，難的是如何在具體業務場景上選擇最合適的方案。無論是哪一種鎖方案都是與業務密切關聯，總之沒有完美的分散式鎖方案，只有最適合當前業務的鎖方案。樂觀鎖寫入失敗會回滾整個事務，因此如果寫入衝突很頻繁的場景不適合使用樂觀鎖，大量的事務回滾會給DB巨大壓力，最終影響到具體業務系統。
總結
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，