Redis怎么實(shí)現分布式鎖

這篇文章主要介紹“怎么實(shí)現分布式鎖”，在日常操作中，相信很多人在Redis怎么實(shí)現分布式鎖問(wèn)題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對大家解答”Redis怎么實(shí)現分布式鎖”的疑惑有所幫助！接下來(lái)，請跟著(zhù)小編一起來(lái)學(xué)習吧！

Redis命令介紹

使用Redis實(shí)現分布式鎖，有兩個(gè)重要函數需要介紹

SETNX命令（SET if Not eXists）
語(yǔ)法：
SETNX key value
功能：
當且僅當 key 不存在，將 key 的值設為 value ，并返回1；若給定的 key 已經(jīng)存在，則 SETNX 不做任何動(dòng)作，并返回0。

GETSET命令
語(yǔ)法：
GETSET key value
功能：
將給定 key 的值設為 value ，并返回 key 的舊值 (old value)，當 key 存在但不是字符串類(lèi)型時(shí)，返回一個(gè)錯誤，當key不存在時(shí)，返回nil。

GET命令
語(yǔ)法：
GET key
功能：
返回 key 所關(guān)聯(lián)的字符串值，如果 key 不存在那么返回特殊值 nil 。

DEL命令
語(yǔ)法：
DEL key [KEY …]
功能：
刪除給定的一個(gè)或多個(gè) key ,不存在的 key 會(huì )被忽略。

兵貴精，不在多。分布式鎖，我們就依靠這四個(gè)命令。但在具體實(shí)現，還有很多細節，需要仔細斟酌，因為在分布式并發(fā)多進(jìn)程中，任何一點(diǎn)出現差錯，都會(huì )導致死鎖，hold住所有進(jìn)程。

加鎖實(shí)現

SETNX 可以直接加鎖操作，比如說(shuō)對某個(gè)關(guān)鍵詞foo加鎖，客戶(hù)端可以嘗試
SETNX foo.lock <current unix time>

如果返回1，表示客戶(hù)端已經(jīng)獲取鎖，可以往下操作，操作完成后，通過(guò)
DEL foo.lock

命令來(lái)釋放鎖。
如果返回0，說(shuō)明foo已經(jīng)被其他客戶(hù)端上鎖，如果鎖是非堵塞的，可以選擇返回調用。如果是堵塞調用調用，就需要進(jìn)入以下個(gè)重試循環(huán)，直至成功獲得鎖或者重試超時(shí)。理想是美好的，現實(shí)是殘酷的。僅僅使用SETNX加鎖帶有競爭條件的，在某些特定的情況會(huì )造成死鎖錯誤。

處理死鎖

在上面的處理方式中，如果獲取鎖的客戶(hù)端端執行時(shí)間過(guò)長(cháng)，進(jìn)程被kill掉，或者因為其他異常崩潰，導致無(wú)法釋放鎖，就會(huì )造成死鎖。所以，需要對加鎖要做時(shí)效性檢測。因此，我們在加鎖時(shí)，把當前時(shí)間戳作為value存入此鎖中，通過(guò)當前時(shí)間戳和Redis中的時(shí)間戳進(jìn)行對比，如果超過(guò)一定差值，認為鎖已經(jīng)時(shí)效，防止鎖無(wú)限期的鎖下去，但是，在大并發(fā)情況，如果同時(shí)檢測鎖失效，并簡(jiǎn)單粗暴的刪除死鎖，再通過(guò)SETNX上鎖，可能會(huì )導致競爭條件的產(chǎn)生，即多個(gè)客戶(hù)端同時(shí)獲取鎖。

C1獲取鎖，并崩潰。C2和C3調用SETNX上鎖返回0后，獲得foo.lock的時(shí)間戳，通過(guò)比對時(shí)間戳，發(fā)現鎖超時(shí)。
C2 向foo.lock發(fā)送DEL命令。
C2 向foo.lock發(fā)送SETNX獲取鎖。
C3 向foo.lock發(fā)送DEL命令，此時(shí)C3發(fā)送DEL時(shí)，其實(shí)DEL掉的是C2的鎖。
C3 向foo.lock發(fā)送SETNX獲取鎖。

此時(shí)C2和C3都獲取了鎖，產(chǎn)生競爭條件，如果在更高并發(fā)的情況，可能會(huì )有更多客戶(hù)端獲取鎖。所以，DEL鎖的操作，不能直接使用在鎖超時(shí)的情況下，幸好我們有GETSET方法，假設我們現在有另外一個(gè)客戶(hù)端C4，看看如何使用GETSET方式，避免這種情況產(chǎn)生。

C1獲取鎖，并崩潰。C2和C3調用SETNX上鎖返回0后，調用GET命令獲得foo.lock的時(shí)間戳T1，通過(guò)比對時(shí)間戳，發(fā)現鎖超時(shí)。
C4 向foo.lock發(fā)送GESET命令，
GETSET foo.lock <current unix time>
并得到foo.lock中老的時(shí)間戳T2

如果T1=T2，說(shuō)明C4獲得時(shí)間戳。
如果T1!=T2，說(shuō)明C4之前有另外一個(gè)客戶(hù)端C5通過(guò)調用GETSET方式獲取了時(shí)間戳，C4未獲得鎖。只能sleep下，進(jìn)入下次循環(huán)中。

現在唯一的問(wèn)題是，C4設置foo.lock的新時(shí)間戳，是否會(huì )對鎖產(chǎn)生影響。其實(shí)我們可以看到C4和C5執行的時(shí)間差值極小，并且寫(xiě)入foo.lock中的都是有效時(shí)間錯，所以對鎖并沒(méi)有影響。
為了讓這個(gè)鎖更加強壯，獲取鎖的客戶(hù)端，應該在調用關(guān)鍵業(yè)務(wù)時(shí)，再次調用GET方法獲取T1，和寫(xiě)入的T0時(shí)間戳進(jìn)行對比，以免鎖因其他情況被執行DEL意外解開(kāi)而不知。以上步驟和情況，很容易從其他參考資料中看到?？蛻?hù)端處理和失敗的情況非常復雜，不僅僅是崩潰這么簡(jiǎn)單，還可能是客戶(hù)端因為某些操作被阻塞了相當長(cháng)時(shí)間，緊接著(zhù) DEL 命令被嘗試執行(但這時(shí)鎖卻在另外的客戶(hù)端手上)。也可能因為處理不當，導致死鎖。還有可能因為sleep設置不合理，導致Redis在大并發(fā)下被壓垮。最為常見(jiàn)的問(wèn)題還有

GET返回nil時(shí)應該走那種邏輯？

第一種走超時(shí)邏輯
C1客戶(hù)端獲取鎖，并且處理完后，DEL掉鎖，在DEL鎖之前。C2通過(guò)SETNX向foo.lock設置時(shí)間戳T0 發(fā)現有客戶(hù)端獲取鎖，進(jìn)入GET操作。
C2 向foo.lock發(fā)送GET命令，獲取返回值T1(nil)。
C2 通過(guò)T0>T1+expire對比，進(jìn)入GETSET流程。
C2 調用GETSET向foo.lock發(fā)送T0時(shí)間戳，返回foo.lock的原值T2
C2 如果T2=T1相等，獲得鎖，如果T2!=T1，未獲得鎖。

第二種情況走循環(huán)走setnx邏輯
C1客戶(hù)端獲取鎖，并且處理完后，DEL掉鎖，在DEL鎖之前。C2通過(guò)SETNX向foo.lock設置時(shí)間戳T0 發(fā)現有客戶(hù)端獲取鎖，進(jìn)入GET操作。
C2 向foo.lock發(fā)送GET命令，獲取返回值T1(nil)。
C2 循環(huán)，進(jìn)入下一次SETNX邏輯

兩種邏輯貌似都是OK，但是從邏輯處理上來(lái)說(shuō)，第一種情況存在問(wèn)題。當GET返回nil表示，鎖是被刪除的，而不是超時(shí)，應該走SETNX邏輯加鎖。走第一種情況的問(wèn)題是，正常的加鎖邏輯應該走SETNX，而現在當鎖被解除后，走的是GETST，如果判斷條件不當，就會(huì )引起死鎖，很悲催，我在做的時(shí)候就碰到了，具體怎么碰到的看下面的問(wèn)題

GETSET返回nil時(shí)應該怎么處理？

C1和C2客戶(hù)端調用GET接口，C1返回T1，此時(shí)C3網(wǎng)絡(luò )情況更好，快速進(jìn)入獲取鎖，并執行DEL刪除鎖，C2返回T2(nil)，C1和C2都進(jìn)入超時(shí)處理邏輯。
C1 向foo.lock發(fā)送GETSET命令，獲取返回值T11(nil)。
C1 比對C1和C11發(fā)現兩者不同，處理邏輯認為未獲取鎖。
C2 向foo.lock發(fā)送GETSET命令，獲取返回值T22(C1寫(xiě)入的時(shí)間戳)。
C2 比對C2和C22發(fā)現兩者不同，處理邏輯認為未獲取鎖。

此時(shí)C1和C2都認為未獲取鎖，其實(shí)C1是已經(jīng)獲取鎖了，但是他的處理邏輯沒(méi)有考慮GETSET返回nil的情況，只是單純的用GET和GETSET值就行對比，至于為什么會(huì )出現這種情況？一種是多客戶(hù)端時(shí)，每個(gè)客戶(hù)端連接Redis的后，發(fā)出的命令并不是連續的，導致從單客戶(hù)端看到的好像連續的命令，到Redis server后，這兩條命令之間可能已經(jīng)插入大量的其他客戶(hù)端發(fā)出的命令，比如DEL,SETNX等。第二種情況，多客戶(hù)端之間時(shí)間不同步，或者不是嚴格意義的同步。

時(shí)間戳的問(wèn)題

我們看到foo.lock的value值為時(shí)間戳，所以要在多客戶(hù)端情況下，保證鎖有效，一定要同步各的時(shí)間，如果各服務(wù)器間，時(shí)間有差異。時(shí)間不一致的客戶(hù)端，在判斷鎖超時(shí)，就會(huì )出現偏差，從而產(chǎn)生競爭條件。
鎖的超時(shí)與否，嚴格依賴(lài)時(shí)間戳，時(shí)間戳本身也是有精度限制，假如我們的時(shí)間精度為秒，從加鎖到執行操作再到解鎖，一般操作肯定都能在一秒內完成。這樣的話(huà)，我們上面的CASE，就很容易出現。所以，最好把時(shí)間精度提升到毫秒級。這樣的話(huà)，可以保證毫秒級別的鎖是安全的。

分布式鎖的問(wèn)題

1：必要的超時(shí)機制：獲取鎖的客戶(hù)端一旦崩潰，一定要有過(guò)期機制，否則其他客戶(hù)端都降無(wú)法獲取鎖，造成死鎖問(wèn)題。
2：分布式鎖，多客戶(hù)端的時(shí)間戳不能保證嚴格意義的一致性，所以在某些特定因素下，有可能存在鎖串的情況。要適度的機制，可以承受小概率的事件產(chǎn)生。
3：只對關(guān)鍵處理節點(diǎn)加鎖，良好的習慣是，把相關(guān)的資源準備好，比如連接數據庫后，調用加鎖機制獲取鎖，直接進(jìn)行操作，然后釋放，盡量減少持有鎖的時(shí)間。
4：在持有鎖期間要不要CHECK鎖，如果需要嚴格依賴(lài)鎖的狀態(tài)，最好在關(guān)鍵步驟中做鎖的CHECK檢查機制，但是根據我們的測試發(fā)現，在大并發(fā)時(shí)，每一次CHECK鎖操作，都要消耗掉幾個(gè)毫秒，而我們的整個(gè)持鎖處理邏輯才不到10毫秒，玩客沒(méi)有選擇做鎖的檢查。
5：sleep學(xué)問(wèn)，為了減少對Redis的壓力，獲取鎖嘗試時(shí)，循環(huán)之間一定要做sleep操作。但是sleep時(shí)間是多少是門(mén)學(xué)問(wèn)。需要根據自己的Redis的QPS，加上持鎖處理時(shí)間等進(jìn)行合理計算。
6：至于為什么不使用Redis的muti，expire，watch等機制，可以查一參考資料，找下原因。

鎖測試數據

未使用sleep

第一種，鎖重試時(shí)未做sleep。單次請求，加鎖，執行，解鎖時(shí)間 

可以看到加鎖和解鎖時(shí)間都很快，當我們使用

ab -n1000 -c100 'http://sandbox6.wanke.etao.com/test/test_sequence.php?tbpm=t'
AB 并發(fā)100累計1000次請求，對這個(gè)方法進(jìn)行壓測時(shí)。 

我們會(huì )發(fā)現，獲取鎖的時(shí)間變成，同時(shí)持有鎖后，執行時(shí)間也變成，而delete鎖的時(shí)間，將近10ms時(shí)間，為什么會(huì )這樣？
1：持有鎖后，我們的執行邏輯中包含了再次調用Redis操作，在大并發(fā)情況下，Redis執行明顯變慢。
2：鎖的刪除時(shí)間變長(cháng)，從之前的0.2ms，變成9.8ms，性能下降近50倍。
在這種情況下，我們壓測的QPS為49，最終發(fā)現QPS和壓測總量有關(guān)，當我們并發(fā)100總共100次請求時(shí)，QPS得到110多。當我們使用sleep時(shí)

使用Sleep時(shí)

單次執行請求時(shí)

我們看到，和不使用sleep機制時(shí)，性能相當。當時(shí)用相同的壓測條件進(jìn)行壓縮時(shí) 

獲取鎖的時(shí)間明顯變長(cháng)，而鎖的釋放時(shí)間明顯變短，僅是不采用sleep機制的一半。當然執行時(shí)間變成就是因為，我們在執行過(guò)程中，重新創(chuàng )建數據庫連接，導致時(shí)間變長(cháng)的。同時(shí)我們可以對比下Redis的命令執行壓力情況 

上圖中細高部分是為未采用sleep機制的時(shí)的壓測圖，矮胖部分為采用sleep機制的壓測圖，通上圖看到壓力減少50%左右，當然，sleep這種方式還有個(gè)缺點(diǎn)QPS下降明顯，在我們的壓測條件下，僅為35，并且有部分請求出現超時(shí)情況。不過(guò)綜合各種情況后，我們還是決定采用sleep機制，主要是為了防止在大并發(fā)情況下把Redis壓垮，很不行，我們之前碰到過(guò)，所以肯定會(huì )采用sleep機制。