1 分布式鎖的疑問

談到分布式鎖，有很多實(shí)現(xiàn)方式，如數(shù)據(jù)庫、redis、ZooKeeper等。提個問題：

• 實(shí)現(xiàn)分布式鎖需要滿足哪些條件呢？

2 數(shù)據(jù)庫實(shí)現(xiàn)分布式鎖

2.1 實(shí)現(xiàn)案例

如使用數(shù)據(jù)庫事務(wù)中的鎖如record lock來實(shí)現(xiàn)，如下所示

1 獲取鎖

public void lock(){connection.setAutoCommit(false)int count = 0;while(count < 4){try{select * from lock where lock_name=xxx for update;if(結(jié)果不為空){//代表獲取到鎖return;}}catch(Exception e){}//為空或者拋異常的話都表示沒有獲取到鎖sleep(1000);count++;}throw new LockException(); }

2 釋放鎖

public void release(){connection.commit(); }

數(shù)據(jù)庫的lock表，lock_name是主鍵,通過for update操作，數(shù)據(jù)庫就會對該行記錄加上record lock，從而阻塞其他人對該記錄的操作。

一旦獲取到了鎖，就可以開始執(zhí)行業(yè)務(wù)邏輯，最后通過connection.commit()操作來釋放鎖。

其他沒有獲取到鎖的就會阻塞在上述select語句上，可能的結(jié)果有2種，在超時之前獲取到了鎖，在超時之前仍未獲取到鎖（這時候會拋出超時異常，然后進(jìn)行重試）

數(shù)據(jù)庫當(dāng)然還有其他方式，如插入一個有唯一約束的數(shù)據(jù)。成功插入則表示獲取到了鎖，釋放鎖就是刪除該記錄。該方案也有很多問題要解決

2.2 存在的問題

首先性能不是特別高。

通過數(shù)據(jù)庫的鎖來實(shí)現(xiàn)多進(jìn)程之間的互斥，但是這貌似也有一個問題：就是sql超時異常的問題

jdbc超時具體有3種超時，具體見深入理解JDBC的超時設(shè)置

• 框架層的事務(wù)超時
• jdbc的查詢超時
• Socket的讀超時

這里只涉及到后2種的超時，jdbc的查詢超時還好（mysql的jdbc驅(qū)動會向服務(wù)器發(fā)送kill query命令來取消查詢），如果一旦出現(xiàn)Socket的讀超時，對于如果是同步通信的Socket連接來說(底層實(shí)現(xiàn)Connection的可能是同步通信也可能是異步通信)，該連接基本上不能使用了，需要關(guān)閉該連接，從新?lián)Q用新的連接，因?yàn)闀霈F(xiàn)請求和響應(yīng)錯亂的情況，比如jedis出現(xiàn)的類型轉(zhuǎn)換異常，詳見Jedis的類型轉(zhuǎn)換異常深究

3 redis實(shí)現(xiàn)分布式鎖

而redis通常可以使用setnx來實(shí)現(xiàn)分布式鎖

3.1 基本版

1 獲取鎖

public void lock(){for(){ret = setnx lock_ley (current_time + lock_timeout)if(ret){//獲取到了鎖break;}//沒有獲取到鎖sleep(100);} }

2 釋放鎖

public void release(){del lock_ley }

setnx來創(chuàng)建一個key，如果key不存在則創(chuàng)建成功返回1，如果key已經(jīng)存在則返回0。依照上述來判定是否獲取到了鎖

獲取到鎖的執(zhí)行業(yè)務(wù)邏輯，完畢后刪除lock_key，來實(shí)現(xiàn)釋放鎖

其他未獲取到鎖的則進(jìn)行不斷重試，直到自己獲取到了鎖

3.2 改進(jìn)版

上述邏輯在正常情況下是OK的，但是一旦獲取到鎖的客戶端掛了，沒有執(zhí)行上述釋放鎖的操作，則其他客戶端就無法獲取到鎖了，所以在這種情況下有2種方式來解決：

• 為lock_key設(shè)置一個過期時間
• 對lock_key的value進(jìn)行判斷是否過期

以第一種為例，在set鍵值的時候帶上過期時間，即使掛了，也會在過期時間之后，其他客戶端能夠重新競爭獲取鎖

public void lock(){while(true){ret = set lock_key identify_value nx ex lock_timeoutif(ret){//獲取到了鎖return;}sleep(100);} }public void release(){value = get lock_keyif(identify_value == value){del lock_key} }

以第二種為例，一旦發(fā)現(xiàn)lock_key的值已經(jīng)小于當(dāng)前時間了，說明該key過期了，然后對該key進(jìn)行g(shù)etset設(shè)置，一旦getset返回值是原來的過期值，說明當(dāng)前客戶端是第一個來操作的，代表獲取到了鎖，一旦getset返回值不是原來過期時間則說明前面已經(jīng)有人修改了，則代表沒有獲取到鎖，詳細(xì)見用Redis實(shí)現(xiàn)分布式鎖，改正如下：

# get lock lock = 0 while lock != 1:timestamp = current_unix_time + lock_timeoutlock = SETNX lock.foo timestampif lock == 1 or (now() > (GET lock.foo) and now() > (GETSET lock.foo timestamp)):break;else:sleep(10ms)# do your job do_job()# release if now() < GET lock.foo:DEL lock.foo

這里看來第二種其實(shí)沒有第一種比較好。

3.3 問題依舊

問題1： lock timeout的存在也使得失去了鎖的意義，即存在并發(fā)的現(xiàn)象。一旦出現(xiàn)鎖的租約時間，就意味著獲取到鎖的客戶端必須在租約之內(nèi)執(zhí)行完畢業(yè)務(wù)邏輯，一旦業(yè)務(wù)邏輯執(zhí)行時間過長，租約到期，就會引發(fā)并發(fā)問題。所以有l(wèi)ock timeout的可靠性并不是那么的高。

問題2： 上述方式僅僅是redis單機(jī)情況下，還存在redis單點(diǎn)故障的問題。如果為了解決單點(diǎn)故障而使用redis的sentinel或者cluster方案，則更加復(fù)雜，引入的問題更多。

4 ZooKeeper實(shí)現(xiàn)分布式鎖

4.1 案例

這也是ZooKeeper客戶端curator的分布式鎖實(shí)現(xiàn)。

1 獲取鎖

public void lock(){path = 在父節(jié)點(diǎn)下創(chuàng)建臨時順序節(jié)點(diǎn)while(true){children = 獲取父節(jié)點(diǎn)的所有節(jié)點(diǎn)if(path是children中的最小的){代表獲取了節(jié)點(diǎn)return;}else{添加監(jiān)控前一個節(jié)點(diǎn)是否存在的watcherwait();}} }watcher中的內(nèi)容{notifyAll(); }

2 釋放鎖

public void release(){刪除上述創(chuàng)建的節(jié)點(diǎn) }

4.2 總結(jié)

ZooKeeper版本的分布式鎖問題相對比較來說少。

• 鎖的占用時間限制：redis就有占用時間限制，而ZooKeeper則沒有，最主要的原因是redis目前沒有辦法知道已經(jīng)獲取鎖的客戶端的狀態(tài)，是已經(jīng)掛了呢還是正在執(zhí)行耗時較長的業(yè)務(wù)邏輯。而ZooKeeper通過臨時節(jié)點(diǎn)就能清晰知道，如果臨時節(jié)點(diǎn)存在說明還在執(zhí)行業(yè)務(wù)邏輯，如果臨時節(jié)點(diǎn)不存在說明已經(jīng)執(zhí)行完畢釋放鎖或者是掛了。由此看來redis如果能像ZooKeeper一樣添加一些與客戶端綁定的臨時鍵，也是一大好事。
• 是否單點(diǎn)故障：redis本身有很多中玩法，如客戶端一致性hash，服務(wù)器端sentinel方案或者cluster方案，很難做到一種分布式鎖方式能應(yīng)對所有這些方案。而ZooKeeper只有一種玩法，多臺機(jī)器的節(jié)點(diǎn)數(shù)據(jù)是一致的，沒有redis的那么多的麻煩因素要考慮。

總體上來說ZooKeeper實(shí)現(xiàn)分布式鎖更加的簡單，可靠性更高。

5 分布式鎖實(shí)現(xiàn)原理總結(jié)

從上面我們經(jīng)歷了3種實(shí)現(xiàn)方式，可以從中總結(jié)下，該怎么去回答最初提出的問題。

5.1 分布式鎖的實(shí)現(xiàn)

在我自己看來有如下3個方面：

• 怎么獲取鎖
• 怎么釋放鎖
• 怎么得知鎖被釋放了

5.1.1 怎么獲取鎖

能夠提供一種方式，多個客戶端并發(fā)操作，只能有一個客戶端能滿足相應(yīng)的要求

如數(shù)據(jù)庫的for update的sql語句、或者插入一個含有唯一約束的數(shù)據(jù)等

如redis的setnx等

如ZooKeeper的求最小節(jié)點(diǎn)的方式

這些都可以保證只能有一個客戶端獲取到了鎖

5.1.2 怎么釋放鎖

場景一般有2種情況：

• 1 正常情況下的釋放鎖
• 2 異常情況下如何釋放鎖（即釋放鎖的操作沒有被執(zhí)行，如掛掉、沒執(zhí)行成功等原因）

如redis正常情況下釋放鎖是刪除lock_key，異常情況下，只能通過lock_key的超時時間了

如ZooKeeper正常情況下釋放鎖是刪除臨時節(jié)點(diǎn)，異常情況下，服務(wù)器也會主動刪除臨時節(jié)點(diǎn)（這種機(jī)制就簡單多了）

5.1.3 怎么得知鎖被釋放了

實(shí)現(xiàn)方式一般有2種情況：

• 1 沒有獲取到鎖的客戶端不斷嘗試獲取鎖
• 2 服務(wù)器端通知客戶端鎖被釋放了

當(dāng)然第二種情況是最優(yōu)的（客戶端所做的無用功最少），如ZooKeeper通過注冊watcher來得到鎖釋放的通知。而數(shù)據(jù)庫、redis沒有辦法來通知客戶端鎖釋放了，那客戶端就只能傻傻的不斷嘗試獲取鎖了。

歡迎來拍磚，相互討論，我相信會越辯越清晰。

總結(jié)

以上是生活随笔為你收集整理的分布式锁的实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。