1. 分布式鎖概述
我們的系統都是分布式部署的,日常開發中,秒殺下單、搶購商品 等等業務場景,為了防?庫存超賣,都需要用到分布式鎖 。
分布式鎖其實就是,控制分布式系統不同進程共同訪問共享資源的一種鎖的實現。如果不同的系統或同一個系統的不同主機之間共享了某個臨界資源,往往需要互斥來防止彼此干擾,以保證一致性。
業界流行的分布式鎖實現,一般有這3種方式:
基于數據庫實現的分布式鎖
基于Redis實現的分布式鎖
基于Zookeeper實現的分布式鎖
基于微服務的思想,構建在 B2C 電商場景下的項目實戰。核心技術棧,是 Spring Boot + Dubbo 。未來,會重構成 Spring Cloud Alibaba 。
項目地址:https://github.com/YunaiV/onemall
2. 基于數據庫的分布式鎖
2.1 數據庫悲觀鎖實現的分布式鎖
可以使用select ... for update 來實現分布式鎖。我們自己的項目,分布式定時任務 ,就使用類似的實現方案,我給大家來展示個簡單版的哈
表結構如下:
CREATETABLE`t_resource_lock`( `key_resource`varchar(45)COLLATEutf8_binNOTNULLDEFAULT'資源主鍵', `status`char(1)COLLATEutf8_binNOTNULLDEFAULT''COMMENT'S,F,P', `lock_flag`int(10)unsignedNOTNULLDEFAULT'0'COMMENT'1是已經鎖0是未鎖', `begin_time`datetimeDEFAULTNULLCOMMENT'開始時間', `end_time`datetimeDEFAULTNULLCOMMENT'結束時間', `client_ip`varchar(45)COLLATEutf8_binNOTNULLDEFAULT'搶到鎖的IP', `time`int(10)unsignedNOTNULLDEFAULT'60'COMMENT'方法生命周期內只允許一個結點獲取一次鎖,單位:分鐘', PRIMARYKEY(`key_resource`)USINGBTREE )ENGINE=InnoDBDEFAULTCHARSET=utf8COLLATE=utf8_bin
加鎖lock方法的偽代碼如下:
@Transcational//一定要加事務 publicbooleanlock(StringkeyResource,inttime){ resourceLock='select*fromt_resource_lockwherekey_resource='#{keySource}'forupdate'; try{ if(resourceLock==null){ //插入鎖的數據 resourceLock=newResourceLock(); resourceLock.setTime(time); resourceLock.setLockFlag(1);//上鎖 resourceLock.setStatus(P);//處理中 resourceLock.setBeginTime(newDate()); intcount="insertintoresourceLock"; if(count==1){ //獲取鎖成功 returntrue; } returnfalse; } }catch(Exceptionx){ returnfalse; } //沒上鎖并且鎖已經超時,即可以獲取鎖成功 if(resourceLock.getLockFlag=='0'&&'S'.equals(resourceLock.getstatus) &&newDate()>=resourceLock.addDateTime(resourceLock.getBeginTime(,time)){ resourceLock.setLockFlag(1);//上鎖 resourceLock.setStatus(P);//處理中 resourceLock.setBeginTime(newDate()); //updateresourceLock; returntrue; }elseif(newDate()>=resourceLock.addDateTime(resourceLock.getBeginTime(,time)){ //超時未正常執行結束,獲取鎖失敗 returnfalse; }else{ returnfalse; } }
解鎖unlock方法的偽代碼如下:
publicvoidunlock(Stringv,status){ resourceLock.setLockFlag(0);//解鎖 resourceLock.setStatus(status);S:表示成功,F表示失敗 //updateresourceLock; return; }
整體流程:
try{ if(lock(keyResource,time)){//加鎖 status=process();//你的業務邏輯處理。 } }finally{ unlock(keyResource,status);//釋放鎖 }
其實這個悲觀鎖實現的分布式鎖,整體的流程還是比較清晰的。就是先select ... for update 鎖住主鍵key_resource那個記錄,如果為空,則可以插入一條記錄,如果已有記錄判斷下狀態和時間 ,是否已經超時 。這里需要注意一下哈,必須要加事務 哈。
2.2 數據庫樂觀鎖實現的分布式鎖
除了悲觀鎖,還可以用樂觀鎖實現分布式鎖 。樂觀鎖,顧名思義,就是很樂觀,每次更新操作,都覺得不會存在并發沖突,只有更新失敗后,才重試。它是基于CAS思想實現的。我以前的公司,扣減余額 就是用這種方案。
搞個version字段,每次更新修改,都會自增加一,然后去更新余額時,把查出來的那個版本號,帶上條件去更新,如果是上次那個版本號,就更新,如果不是,表示別人并發修改過了,就繼續重試。
大概流程如下:
查詢版本號和余額
selectversion,balancefromaccountwhereuser_id='666';
假設查到版本號是oldVersion=1.
邏輯處理,判斷余額
if(balance<扣減金額){ ???return; } left_balance?=?balance?-?扣減金額;
進行扣減余額
updateaccountsetbalance=#{left_balance},version=version+1whereversion =#{oldVersion}andbalance>=#{left_balance}anduser_id='666';
大家可以看下這個流程圖哈:
這種方式適合并發不高 的場景,一般需要設置一下重試的次數
3.基于Redis實現的分布式鎖
Redis分布式鎖一般有以下這幾種實現方式:
setnx + expire
setnx + value值是過期時間
set的擴展命令(set ex px nx)
set ex px nx + 校驗唯一隨機值,再刪除
Redisson
Redisson + RedLock
3.1 setnx + expire
聊到Redis分布式鎖,很多小伙伴反手就是setnx + expire,如下:
if(jedis.setnx(key,lock_value)==1){//setnx加鎖 expire(key,100);//設置過期時間 try{ dosomething//業務處理 }catch(){ } finally{ jedis.del(key);//釋放鎖 } }
這段代碼是可以加鎖成功,但是你有沒有發現問題,加鎖操作和設置超時時間是分開的 。假設在執行完setnx加鎖后,正要執行expire設置過期時間時,進程crash掉或者要重啟維護了,那這個鎖就長生不老 了,別的線程永遠獲取不到鎖啦,所以分布式鎖不能這么實現 !
3.2 setnx + value值是過期時間
longexpires=System.currentTimeMillis()+expireTime;//系統時間+設置的過期時間 StringexpiresStr=String.valueOf(expires); //如果當前鎖不存在,返回加鎖成功 if(jedis.setnx(key,expiresStr)==1){ returntrue; } //如果鎖已經存在,獲取鎖的過期時間 StringcurrentValueStr=jedis.get(key); //如果獲取到的過期時間,小于系統當前時間,表示已經過期 if(currentValueStr!=null&&Long.parseLong(currentValueStr)
日常開發中,有些小伙伴就是這么實現分布式鎖的,但是會有這些缺點 :
過期時間是客戶端自己生成的,分布式環境下,每個客戶端的時間必須同步。
沒有保存持有者的唯一標識,可能被別的客戶端釋放/解鎖 。
鎖過期的時候,并發多個客戶端同時請求過來,都執行了jedis.getSet(),最終只能有一個客戶端加鎖成功,但是該客戶端鎖的過期時間,可能被別的客戶端覆蓋。
3.3 set的擴展命令(set ex px nx)
這個命令的幾個參數分別表示什么意思呢?跟大家復習一下:
SETkeyvalue[EXseconds][PXmilliseconds][NX|XX]
EX second :設置鍵的過期時間為second秒。
PX millisecond :設置鍵的過期時間為millisecond毫秒。
NX :只在鍵不存在時,才對鍵進行設置操作。
XX :只在鍵已經存在時,才對鍵進行設置操作。
if(jedis.set(key,lock_value,"NX","EX",100s)==1){//加鎖 try{ dosomething//業務處理 }catch(){ } finally{ jedis.del(key);//釋放鎖 } }
這個方案可能存在這樣的問題:
鎖過期釋放了,業務還沒執行完。
鎖被別的線程誤刪。
有些伙伴可能會有個疑問,就是鎖為什么會被別的線程誤刪 呢?假設并發多線程場景下,線程A獲得了鎖,但是它沒釋放鎖的話,線程B是獲取不到鎖的 ,所以按道理它是執行不到加鎖下面的代碼滴,怎么會導致鎖被別的線程誤刪呢?
假設線程A和B,都想用key加鎖,最后A搶到鎖加鎖成功,但是由于執行業務邏輯的耗時很長,超過了設置的超時時間100s。這時候,Redis就自動釋放了key鎖。這時候線程B就可以加鎖成功了,接下啦,它也執行業務邏輯處理。假設碰巧這時候,A執行完自己的業務邏輯,它就去釋放鎖,但是它就把B的鎖給釋放了。
3.4 set ex px nx + 校驗唯一隨機值,再刪除
為了解決鎖被別的線程誤刪 問題。可以在set ex px nx的基礎上,加上個校驗的唯一隨機值,如下:
if(jedis.set(key,uni_request_id,"NX","EX",100s)==1){//加鎖 try{ dosomething//業務處理 }catch(){ } finally{ //判斷是不是當前線程加的鎖,是才釋放 if(uni_request_id.equals(jedis.get(key))){ jedis.del(key);//釋放鎖 } } }
在這里,判斷當前線程加的鎖和釋放鎖不是一個原子操作 。如果調用jedis.del()釋放鎖的時候,可能這把鎖已經不屬于當前客戶端 ,會解除他人加的鎖。
一般可以用lua腳本來包一下。lua腳本如下:
ifredis.call('get',KEYS[1])==ARGV[1]then returnredis.call('del',KEYS[1]) else return0 end;
這種方式比較不錯了,一般情況下,已經可以使用這種實現方式。但是還是存在:鎖過期釋放了,業務還沒執行完的問題 。
3.5 Redisson
對于可能存在鎖過期釋放,業務沒執行完 的問題。我們可以稍微把鎖過期時間設置長一些,大于正常業務處理時間就好啦。如果你覺得不是很穩,還可以給獲得鎖的線程,開啟一個定時守護線程,每隔一段時間檢查鎖是否還存在,存在則對鎖的過期時間延長,防止鎖過期提前釋放。
當前開源框架Redisson解決了這個問題。可以看下Redisson底層原理圖:
只要線程一加鎖成功,就會啟動一個watch dog看門狗,它是一個后臺線程,會每隔10秒檢查一下,如果線程1還持有鎖,那么就會不斷的延長鎖key的生存時間。因此,Redisson就是使用watch dog解決了鎖過期釋放,業務沒執行完問題 。
3.6 Redisson + RedLock
前面六種方案都只是基于Redis單機版 的分布式鎖討論,還不是很完美。因為Redis 一般都是集群部署的:
如果線程一在Redis的master節點上拿到了鎖,但是加鎖的key還沒同步到slave節點。恰好這時,master節點發生故障,一個slave節點就會升級為master節點。線程二就可以順理成章獲取同個key的鎖啦,但線程一也已經拿到鎖了,鎖的安全性就沒了。
為了解決這個問題,Redis作者antirez提出一種高級的分布式鎖算法:Redlock 。它的核心思想是這樣的:
部署多個Redis master,以保證它們不會同時宕掉。并且這些master節點是完全相互獨立的,相互之間不存在數據同步。同時,需要確保在這多個master實例上,是與在Redis單實例,使用相同方法來獲取和釋放鎖。
我們假設當前有5個Redis master節點,在5臺服務器上面運行這些Redis實例。
RedLock的實現步驟:獲取當前時間,以毫秒為單位。
按順序向5個master節點請求加鎖。客戶端設置網絡連接和響應超時時間,并且超時時間要小于鎖的失效時間。(假設鎖自動失效時間為10秒,則超時時間一般在5-50毫秒之間,我們就假設超時時間是50ms吧)。如果超時,跳過該master節點,盡快去嘗試下一個master節點。
客戶端使用當前時間減去開始獲取鎖時間(即步驟1記錄的時間),得到獲取鎖使用的時間。當且僅當超過一半(N/2+1,這里是5/2+1=3個節點)的Redis master節點都獲得鎖,并且使用的時間小于鎖失效時間時,鎖才算獲取成功。(如上圖,10s> 30ms+40ms+50ms+4m0s+50ms)
如果取到了鎖,key的真正有效時間就變啦,需要減去獲取鎖所使用的時間。
如果獲取鎖失敗(沒有在至少N/2+1個master實例取到鎖,有或者獲取鎖時間已經超過了有效時間),客戶端要在所有的master節點上解鎖(即便有些master節點根本就沒有加鎖成功,也需要解鎖,以防止有些漏網之魚)。
簡化下步驟就是:
按順序向5個master節點請求加鎖
根據設置的超時時間來判斷,是不是要跳過該master節點。
如果大于等于3個節點加鎖成功,并且使用的時間小于鎖的有效期,即可認定加鎖成功啦。
如果獲取鎖失敗,解鎖!
Redisson實現了redLock版本的鎖 ,有興趣的小伙伴,可以去了解一下哈~
4. Zookeeper分布式鎖
在學習Zookeeper分布式鎖之前,我們復習一下Zookeeper的節點哈。
Zookeeper的節點Znode有四種類型:
持久節點 :默認的節點類型。創建節點的客戶端與zookeeper斷開連接后,該節點依舊存在。
持久節點順序節點 :所謂順序節點,就是在創建節點時,Zookeeper根據創建的時間順序給該節點名稱進行編號,持久節點順序節點就是有順序的持久節點。
臨時節點 :和持久節點相反,當創建節點的客戶端與zookeeper斷開連接后,臨時節點會被刪除。
臨時順序節點 :有順序的臨時節點。
Zookeeper分布式鎖實現應用了臨時順序節點 。這里不貼代碼啦,來講下zk分布式鎖的實現原理吧。
4.1 zk獲取鎖過程
當第一個客戶端請求過來時,Zookeeper客戶端會創建一個持久節點locks。如果它(Client1)想獲得鎖,需要在locks節點下創建一個順序節點lock1.如圖
接著,客戶端Client1會查找locks下面的所有臨時順序子節點,判斷自己的節點lock1是不是排序最小的那一個,如果是,則成功獲得鎖。
這時候如果又來一個客戶端client2前來嘗試獲得鎖,它會在locks下再創建一個臨時節點lock2
客戶端client2一樣也會查找locks下面的所有臨時順序子節點,判斷自己的節點lock2是不是最小的,此時,發現lock1才是最小的,于是獲取鎖失敗。獲取鎖失敗,它是不會甘心的,client2向它排序靠前的節點lock1注冊Watcher事件,用來監聽lock1是否存在,也就是說client2搶鎖失敗進入等待狀態。
此時,如果再來一個客戶端Client3來嘗試獲取鎖,它會在locks下再創建一個臨時節點lock3
同樣的,client3一樣也會查找locks下面的所有臨時順序子節點,判斷自己的節點lock3是不是最小的,發現自己不是最小的,就獲取鎖失敗。它也是不會甘心的,它會向在它前面的節點lock2注冊Watcher事件,以監聽lock2節點是否存在。
4.2 釋放鎖
我們再來看看釋放鎖的流程,Zookeeper的客戶端業務完成或者發生故障,都會刪除臨時節點,釋放鎖。如果是任務完成,Client1會顯式調用刪除lock1的指令
如果是客戶端故障了,根據臨時節點得特性,lock1是會自動刪除的
lock1節點被刪除后,Client2可開心了,因為它一直監聽著lock1。lock1節點刪除,Client2立刻收到通知,也會查找locks下面的所有臨時順序子節點,發下lock2是最小,就獲得鎖。
同理,Client2獲得鎖之后,Client3也對它虎視眈眈,啊哈哈~
Zookeeper設計定位就是分布式協調,簡單易用。如果獲取不到鎖,只需添加一個監聽器即可,很適合做分布式鎖。
Zookeeper作為分布式鎖也缺點:如果有很多的客戶端頻繁的申請加鎖、釋放鎖,對于Zookeeper集群的壓力會比較大。
5. 三種分布式鎖對比
5.1 數據庫分布式鎖實現
優點:
簡單,使用方便,不需要引入Redis、zookeeper等中間件。
缺點:
不適合高并發的場景
db操作性能較差;
5.2 Redis分布式鎖實現
優點:
性能好,適合高并發場景
較輕量級
有較好的框架支持,如Redisson
缺點:
過期時間不好控制
需要考慮鎖被別的線程誤刪場景
5.3 Zookeeper分布式鎖實現
缺點:
性能不如redis實現的分布式鎖
比較重的分布式鎖。
優點:
有較好的性能和可靠性
有封裝較好的框架,如Curator
5.4 對比匯總
從性能角度(從高到低)Redis > Zookeeper >= 數據庫;
從理解的難易程度角度(從低到高)數據庫 > Redis > Zookeeper;
從實現的復雜性角度(從低到高)Zookeeper > Redis > 數據庫;
從可靠性角度(從高到低)Zookeeper > Redis > 數據庫。
審核編輯:劉清
-
數據庫
+關注
關注
7文章
3794瀏覽量
64362 -
Lua語言
+關注
關注
0文章
9瀏覽量
1490 -
Redis
+關注
關注
0文章
374瀏覽量
10871
原文標題:面試必備:聊聊分布式鎖的多種實現!
文章出處:【微信號:芋道源碼,微信公眾號:芋道源碼】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論