RedLock 原始碼分析及優化

redlock：全名叫做 redis distributed lock;即使用redis實現的分布式鎖；

使用場景：多個服務間保證同一時刻同一時間段內同一使用者只能有乙個請求（防止關鍵業務出現併發攻擊）；

這個鎖的演算法實現了多redis例項的情況，相對於單redis節點來說，優點在於防止了單節點故障造成整個服務停止執行的情況；並且在多節點中鎖的設計，及多節點同時崩潰等各種意外情況有自己獨特的設計方法；

1.ttl：time to live;指redis key 的過期時間或有效生存時間

2.**clock drift:時鐘漂移；**指兩個電腦間時間流速基本相同的情況下，兩個電腦（或兩個程序間）時間的差值；如果電腦距離過遠會造成時鐘漂移值過大

最低保證分布式鎖的有效性及安全性的要求如下：

1.互斥；任何時刻只能有乙個client獲取鎖

2.釋放死鎖；即使鎖定資源的服務崩潰或者分割槽，仍然能釋放鎖

3.容錯性；只要多數redis節點（一半以上）在使用，client就可以獲取和釋放鎖

網上講的基於故障轉移實現的redis主從無法真正實現redlock:

因為redis在進行主從複製時是非同步完成的，比如在clienta獲取鎖後，主redis複製資料到從redis過程中崩潰了，導致沒有複製到從redis中，然後從redis選舉出乙個公升級為主redis,造成新的主redis沒有clienta 設定的鎖，這是clientb嘗試獲取鎖，並且能夠成功獲取鎖，導致互斥失效；

思考題：這個失敗的原因是因為從redis立刻公升級為主redis，如果能夠過ttl時間再公升級為主redis（延遲公升級）後，或者立刻公升級為主redis但是過ttl的時間後再執行獲取鎖的任務，就能成功產生互斥效果；是不是這樣就能實現基於redis主從的redlock;

防止單點故障,服務繼續使用

.獲取當前時間戳

2.client嘗試按照順序使用相同的key,value獲取所有redis服務的鎖，在獲取鎖的過程中的獲取時間比鎖過期時間短很多，這是為了不要過長時間等待已經關閉的redis服務。並且試著獲取下乙個redis例項。

比如：ttl為5s,設定獲取鎖最多用1s，所以如果一秒內無法獲取鎖，就放棄獲取這個鎖，從而嘗試獲取下個鎖

3.client通過獲取所有能獲取的鎖後的時間減去第一步的時間，這個時間差要小於ttl時間並且至少有3個redis例項成功獲取鎖，才算真正的獲取鎖成功

4.如果成功獲取鎖，則鎖的真正有效時間是 ttl減去第三步的時間差的時間；比如：ttl 是5s,獲取所有鎖用了2s,則真正鎖有效時間為3s(其實應該再減去時鐘漂移);

5.如果客戶端由於某些原因獲取鎖失敗，便會開始解鎖所有redis例項；因為可能已經獲取了小於3個鎖，必須釋放，否則影響其他client獲取鎖

可以看成是同步演算法；因為即使程序間（多個電腦間）沒有同步時鐘，但是每個程序時間流速大致相同；並且時鐘漂移相對於ttl叫小，可以忽略，所以可以看成同步演算法；（不夠嚴謹，演算法上要算上時鐘漂移，因為如果兩個電腦在地球兩端，則時鐘漂移非常大）

一定要控制失敗重新獲取鎖的次數

當client不能獲取鎖時，應該在隨機時間後重試獲取鎖；並且最好在同一時刻併發的把set命令傳送給所有redis例項；而且對於已經獲取鎖的client在完成任務後要及時釋放鎖，這是為了節省時間；

由於釋放鎖時會判斷這個鎖的value是不是自己設定的，如果是才刪除；所以在釋放鎖時非常簡單，只要向所有例項都發出釋放鎖的命令，不用考慮能否成功釋放鎖；

思路父程序其乙個子程序，父程序監控子程序，子程序執行程式，父程序監控，一半的過期時間後，子程序存在，去續期鎖的有效期，子程序退出，釋放鎖

**尚未完善，需壓測，未完待續

RedLock 原始碼分析及優化

UGUI合批原始碼分析及優化

JDK類載入機制原始碼分析及原始碼分析

Spring設計及原始碼分析

RedLock 原始碼分析及優化

UGUI合批原始碼分析及優化

JDK類載入機制原始碼分析及原始碼分析

Spring設計及原始碼分析

相關推薦