redis分佈式鎖的實現（3）- RedLock理論實現分佈式鎖

1. redis分佈式鎖的實現(1)
2. redis分佈式鎖的實現(2)

• 前2篇的介紹以及分佈式鎖的實現都是基於redis單實例節點的，在redis哨兵模式和集羣下，還會存在如下狀況。
  • 因爲 Redis在進行主從複製時是異步完成的，好比在A獲取鎖後，主redis還沒來得及把數據複製到從節點就崩潰了，而後從 其餘salve 節點中選舉出一個升級爲主redis,這個時候其餘客戶端請求過來獲取鎖的時候就馬上獲取到了這就會致使系統中一樣一把鎖會被兩個客戶端同時持有，致使互斥（任什麼時候刻只能有一個client獲取鎖）失效，不安全性由此產生。不過，這種狀況也只是在主從發生failover 的狀況下才會產生，並且持續時間極短，通常狀況下是能夠容忍這種問題的。

Redlock 原理分析（轉）

redis官網關於redLock算法介紹

假設有5個徹底獨立的redis主服務器

1. 獲取當前時間戳

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獲取鎖

RedLock算法是不是異步算法？

能夠當作是同步算法；由於 即便進程間（多個電腦間）沒有同步時鐘，可是每一個進程時間流速大體相同；而且時鐘漂移相對於TTL叫小，能夠忽略，因此能夠當作同步算法

RedLock失敗重試

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

RedLock釋放鎖

因爲釋放鎖時會判斷這個鎖的value是否是本身設置的，若是是才刪除；因此在釋放鎖時很是簡單，只要向全部實例都發出釋放鎖的命令，不用考慮可否成功釋放鎖；

RedLock注意點（Safety arguments）:

1. 先假設client獲取全部實例，全部實例包含相同的key和過時時間(TTL) ,但每一個實例set命令時間不一樣致使不能同時過時，第一個set命令以前是T1,最後一個set命令後爲T2,則此client有效獲取鎖的最小時間爲TTL-(T2-T1)-時鐘漂移;

2. 對於以N/2+ 1(也就是一半以 上)的方式判斷獲取鎖成功，是由於若是小於一半判斷爲成功的話，有可能出現多個client都成功獲取鎖的狀況， 從而使鎖失效

3. 一個client鎖定大多數事例耗費的時間大於或接近鎖的過時時間，就認爲鎖無效，而且解鎖這個redis實例(不執行業務) ;只要在TTL時間內成功獲取一半以上的鎖即是有效鎖;不然無效

系統有活性的三個特徵

1. 可以自動釋放鎖

2. 在獲取鎖失敗（不到一半以上），或任務完成後 可以自動釋放鎖，不用等到其自動過時

3. 在client重試獲取哦鎖前（第一次失敗到第二次重試時間間隔）大於第一次獲取鎖消耗的時間；

4. 重試獲取鎖要有必定次數限制

鎖續約

若是Client進行的工做耗時較短，那麼能夠默認使用一個較小的鎖有效期，而後實現一個鎖續約機制。

當一個Client在工做計算到一半時發現鎖的剩餘有效期不足。能夠向Redis實例發送續約鎖的Lua腳本。若是Client在必定的期限內(耗間與申請鎖的耗時接近)成功的續約了半數以上的實例，那麼續約鎖成功。

爲了提升系統的可用性，每一個Client申請鎖續約的次數須要有一個最大限制，避免其不斷續約形成該key長時間不可用。

RedLock性能及崩潰恢復的相關解決方法

1. 若是redis沒有持久化功能，在clientA獲取鎖成功後，全部redis重啓，clientB可以再次獲取到鎖，這樣違法了鎖的排他互斥性;

2. 若是啓動AOF永久化存儲，事情會好些， 舉例:當咱們重啓redis後，因爲redis過時機制是按照unix時間戳走的，因此在重啓後，而後會按照規定的時間過時，不影響業務;可是因爲AOF同步到磁盤的方式默認是每秒-次，若是在一秒內斷電，會致使數據丟失，當即重啓會形成鎖互斥性失效;但若是同步磁盤方式使用Always(每個寫命令都同步到硬盤)形成性能急劇降低;因此在鎖徹底有效性和性能方面要有所取捨;

3. 有效解決既保證鎖徹底有效性及性能高效及即便斷電狀況的方法是redis同步到磁盤方式保持默認的每秒，在redis不管由於什麼緣由停掉後要等待TTL時間後再重啓(學名:延遲重啓) ;缺點是 在TTL時間內服務至關於暫停狀態;

總結：

1.TTL時長 要大於正常業務執行的時間+獲取全部redis服務消耗時間+時鐘漂移

2.獲取redis全部服務消耗時間要 遠小於TTL時間，而且獲取成功的鎖個數要 在總數的通常以上:N/2+1

3.嘗試獲取每一個redis實例鎖時的時間要 遠小於TTL時間

4.嘗試獲取全部鎖失敗後 從新嘗試必定要有必定次數限制

5.在redis崩潰後（不管一個仍是全部），要延遲TTL時間重啓redis

6.在實現多redis節點時要結合單節點分佈式鎖算法 共同實現

《Redis官方文檔》用Redis構建分佈式鎖

問題

假設有5個redis實例a，b，c，d，e，線程A分別加鎖，而後a，b，c加鎖成功，由於網絡分區問題，d，e失敗。同時，線程B也加鎖，由於網絡分區問題，a，b加鎖失敗，可是d，e加鎖成功。這時候，顯然線程A會得到鎖，可是若是這時候c的master掛了，而後切換成了slave，slave中沒有A加鎖的信息，恰巧這時線程B對c加鎖的命令到了，那線程B就會加鎖成功，這時候，線程A和B都給三個節點加鎖成功了，他們就同時擁有鎖。因此仍是不是徹底可靠的!!!

Redisson實現分佈式鎖

推薦你們閱讀這個Redisson官方文檔 - Redisson項目介紹