国产探花免费观看_亚洲丰满少妇自慰呻吟_97日韩有码在线_资源在线日韩欧美_一区二区精品毛片,辰东完美世界有声小说,欢乐颂第一季,yy玄幻小说排行榜完本

首頁 > 數據庫 > MySQL > 正文

MySQL借助DB實現分布式鎖思路詳解

2020-01-18 20:41:31
字體:
來源:轉載
供稿:網友

前言

無論是單機鎖還是分布式鎖,原理都是基于共享的數據,判斷當前操作的行為。對于單機則是共享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巨大壓力,最終影響到具體業務系統。

總結

分布式鎖的原理實際上很容易理解,難的是如何在具體業務場景上選擇最合適的方案。無論是哪一種鎖方案都是與業務密切關聯,總之沒有完美的分布式鎖方案,只有最適合當前業務的鎖方案。

好了,以上就是這篇文章的全部內容了,希望本文的內容對大家的學習或者工作具有一定的參考學習價值,謝謝大家對武林網的支持。

發表評論 共有條評論
用戶名: 密碼:
驗證碼: 匿名發表
主站蜘蛛池模板: 鹤岗市| 合川市| 韩城市| 搜索| 花莲县| 柘荣县| 勐海县| 南昌县| 雷波县| 桐梓县| 沅陵县| 成武县| 广南县| 集安市| 牡丹江市| 蒙城县| 博客| 枞阳县| 新竹市| 锦屏县| 大方县| 大余县| 奉化市| 高雄市| 临高县| 诏安县| 定结县| 荣成市| 开阳县| 柞水县| 行唐县| 历史| 山丹县| 隆林| 页游| 宝应县| 西华县| 泰来县| 平陆县| 博客| 垫江县|