1. 前言
分布式應(yīng)用中,有時我們需要一個方法在同一時間只能被一個線程執(zhí)行。此時我們有可能會使用到分布式鎖。
分布式鎖需要具備以下特征:
- 互斥性 同一時刻鎖只能被一個線程持有。
- 超時釋放 超時釋放主要是用來避免死鎖,防止不必要的線程等待和資源浪費
- 可重入性 一個線程在持有鎖的情況下,可以再次請求加鎖
- 高性能,高可用 加鎖釋放鎖的操作盡量使用更少的資源,提高性能。同時也要保證高可用,防止分布式鎖意外失效
目前比較多的分布式鎖有下面的方案:
- 基于數(shù)據(jù)庫實現(xiàn)分布式鎖
- 基于緩存(redis, Hazelcast)等實現(xiàn)分布式鎖
- 基于Zookeeper實現(xiàn)分布式鎖
2. 數(shù)據(jù)庫分布式鎖
2.1基于表記錄的分布式鎖
在數(shù)據(jù)庫中創(chuàng)建一個鎖表,并且在需要的字段上創(chuàng)建唯一索引,使用鎖的時候就插入數(shù)據(jù),插入成功則獲得鎖,執(zhí)行結(jié)束后,就刪除數(shù)據(jù)。也可以加上version控制,使之成為樂觀鎖。
- 獲取鎖:成功插入數(shù)據(jù)
- 執(zhí)行業(yè)務(wù)邏輯
- 釋放鎖:刪除數(shù)據(jù)
2.2基于數(shù)據(jù)庫行鎖的分布式鎖
使用select * For update來獲取數(shù)據(jù)庫數(shù)據(jù)鎖, where之后的條件加入唯一索引,則表示使用了行鎖。其分布式鎖使用順序如下。
- 獲取鎖:SELECT * FROM database_lock WHERE id = 1 FOR UPDATE;。
- 執(zhí)行業(yè)務(wù)邏輯。
- 釋放鎖:COMMIT。
3 Zookeeper分布式鎖
Zookeepe可以實現(xiàn)分布式鎖主要是因為多個線程去Zookpeeper中創(chuàng)建同一個節(jié)點時,只有一個線程可以創(chuàng)建成功。
Zookeeper中有臨時節(jié)點,持久化節(jié)點。其中臨時節(jié)點在服務(wù)端session失效后,節(jié)點就會被刪除。相對而言,持久化節(jié)點在服務(wù)端session失效后,也不會被刪除,而是需要客戶端主動刪除。
在上述類型系節(jié)點之后增加一個數(shù)字后綴,即路徑+數(shù)字后綴,這樣可以保證其唯一性和有序性。
其分布式鎖實現(xiàn)原理如下:
- 創(chuàng)建一個lock目錄給分布式鎖使用
- 某個線程想要獲取鎖就在此目錄下創(chuàng)建臨時順序節(jié)點
- 獲取此目錄下的所有子節(jié)點,然后查找比自己序號小的節(jié)點,如果不存在,則當前線程創(chuàng)建的節(jié)點是最小節(jié)點,此時獲得鎖。
- 其他線程想要獲取鎖,同樣是創(chuàng)建臨時有序節(jié)點,如果是最小序號節(jié)點則獲得鎖,否則監(jiān)聽比自己小的次小節(jié)點。
- 持有分布式鎖的線程操作完成之后,刪除自己的臨時節(jié)點,次大節(jié)點監(jiān)聽到變更事件之后,判斷自己是最小序號節(jié)點的話,則獲得鎖。
Zookeeper實現(xiàn)分布式鎖具有高可用,可重入,阻塞等特點,由于臨時節(jié)點在客戶端斷開的時候就會被自動刪除,所以不用擔心死鎖問題。但是頻繁刪除和創(chuàng)建節(jié)點,性能上會比Redis分布式鎖低。
4 Redis分布式鎖
4.1 SETNX
setnx命令只會在key不存在的情況下將key設(shè)置為value值, 其中key和 value值均可以設(shè)置成和業(yè)務(wù)相關(guān)的的命名。但是不滿足超時釋放的要求。
如果使用expire設(shè)置過期時間,也有可能在setnx成功后,由于各種原因,expire沒有執(zhí)行成功,從而導致鎖不能超時釋放。
4.2 SETNX 擴展命令
set key value [EX seconds] [PX milliseconds] [NX|XX]
#EX 設(shè)置過期時間,單位為秒 set lock VALUE EX 10
#PX 設(shè)置過期時間,單位為毫秒 set lock VALUE PX 10000
#NX key不存在時才設(shè)置key的值 set lock VALUE EX 10 NX
#XX key存在時才設(shè)置key SET lock VALUE EX 10 XX
set 擴展命令可以完全取代 SETNX, SETEX, PSETEX 等功能。
可以使用set擴展功能完成設(shè)置過期時間, 并且是原子操作。
上述分布式鎖也有一些問題:
- 如果線程獲取鎖之后,執(zhí)行時間過長,鎖提前釋放。
- 如果線程A未執(zhí)行完操作,鎖超時釋放,此時線程B又獲取了鎖。線程B持有鎖,但是A線程有可能執(zhí)行DEL操作釋放鎖。
需要避免在長時間執(zhí)行的任務(wù)中使用上述分布式鎖,而且未按時執(zhí)行完的線程不影響其最終結(jié)果。另外可以在鎖的value設(shè)置一些唯一值,刪除key之前驗證是否持有鎖。并且驗證和刪除需要使用Lua腳本保證其刪除操作的原子性。
上述分布式鎖還需要解決一個可重入性的問題。
4.3 Redisson 分布式鎖
Redisson是基于Redis的Java內(nèi)存數(shù)據(jù)網(wǎng)格,充分利用了Redis鍵值數(shù)據(jù)庫提供的一系列優(yōu)勢。同時提供功能豐富的分布式鎖。
Resisson內(nèi)部會有一個監(jiān)控鎖的守護線程,在redisson實例被關(guān)閉前,不斷延長鎖的有效期。并且可以自定義超時檢查時間間隔,同時還可以指定加鎖時間。另外還支持公平鎖(Fair Lock),聯(lián)鎖(MultiLock),紅鎖(RedLock),讀寫鎖(ReadWriteLock)以及RSemaphore和RCountDownLatch等類似Java提供的各種多線程工具等。
其中RedLock是基于多個Redis集群關(guān)聯(lián)的鎖,可以大大提高鎖的可用性及安全性。
-
數(shù)據(jù)
+關(guān)注
關(guān)注
8文章
7224瀏覽量
90198 -
數(shù)據(jù)庫
+關(guān)注
關(guān)注
7文章
3868瀏覽量
65027 -
分布式
+關(guān)注
關(guān)注
1文章
953瀏覽量
74788 -
線程
+關(guān)注
關(guān)注
0文章
507瀏覽量
19867 -
服務(wù)端
+關(guān)注
關(guān)注
0文章
66瀏覽量
7105
發(fā)布評論請先 登錄
相關(guān)推薦
分布式軟件系統(tǒng)
小白求教:labview連接分布式數(shù)據(jù)庫
分布式數(shù)據(jù)庫有什么優(yōu)缺點?
HarmonyOS分布式數(shù)據(jù)庫,為啥這么牛?
【木棉花】分布式數(shù)據(jù)庫
分布式數(shù)據(jù)庫,什么是分布式數(shù)據(jù)庫
分布式數(shù)據(jù)庫控制協(xié)調(diào)體系結(jié)構(gòu)的研究與實現(xiàn)
Redis 分布式鎖的正確實現(xiàn)方式
為什么我們需要分布式數(shù)據(jù)庫
數(shù)據(jù)庫如何走向分布式

**分布式數(shù)據(jù)庫|數(shù)據(jù)庫數(shù)據(jù)類型**
深入理解redis分布式鎖

評論