RedLock(redis分佈式鎖)原理分析
Redlock：全名叫做 Redis Distributed Lock;即使用redis實現的分佈式鎖；
使用場景：多個服務間保證同一時刻同一時間段內同一用戶只能有一個請求（防止關鍵業務出現併發攻擊）；
官網文檔地址如下：
https://redis.io/topics/distlock
這個鎖的算法實現了多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;
Redis 單例
-
使用set命令提供了nx 和expires,成功返回true,失敗返回false,如果同時有A B C搶鎖,爲了保證A執行完事務,釋放鎖,保證A釋放的是A的鎖,這時候A B C 需要不同的value,保證釋放的是自己的鎖
-
在完成業務釋放自己的鎖的時候最好使用Lua腳本
![在這裏插入圖片描述]()
保證原子性
![]()
多節點redis實現分佈式鎖算法
防止單點故障,服務繼續使用
.獲取當前時間戳
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）:
-
先假設client獲取所有實例，所有實例包含相同的key和過期時間(TTL) ,但每個實例set命令時間不同導致不能同時過期，第一個set命令之前是T1,最後一個set命令後爲T2,則此client有效獲取鎖的最小時間爲TTL-(T2-T1)-時鐘漂移;
-
對於以N/2+ 1(也就是一半以 上)的方式判斷獲取鎖成功，是因爲如果小於一半判斷爲成功的話，有可能出現多個client都成功獲取鎖的情況， 從而使鎖失效
-
一個client鎖定大多數事例耗費的時間大於或接近鎖的過期時間，就認爲鎖無效，並且解鎖這個redis實例(不執行業務) ;只要在TTL時間內成功獲取一半以上的鎖便是有效鎖;否則無效
-
記得設計失敗獲取鎖的重試次數
系統有活性的三個特徵
-
能夠自動釋放鎖
-
在獲取鎖失敗（不到一半以上），或任務完成後 能夠自動釋放鎖，不用等到其自動過期
-
在client重試獲取哦鎖前（第一次失敗到第二次重試時間間隔）大於第一次獲取鎖消耗的時間；
-
重試獲取鎖要有一定次數限制
RedLock性能及崩潰恢復的相關解決方法
-
如果redis沒有持久化功能，在clientA獲取鎖成功後，所有redis重啓，clientB能夠再次獲取到鎖，這樣違法了鎖的排他互斥性;
-
如果啓動AOF永久化存儲，事情會好些， 舉例:當我們重啓redis後，由於redis過期機制是按照unix時間戳走的，所以在重啓後，然後會按照規定的時間過期，不影響業務;但是由於AOF同步到磁盤的方式默認是每秒-次，如果在一秒內斷電，會導致數據丟失，立即重啓會造成鎖互斥性失效;但如果同步磁盤方式使用Always(每一個寫命令都同步到硬盤)造成性能急劇下降;所以在鎖完全有效性和性能方面要有所取捨;
-
有效解決既保證鎖完全有效性及性能高效及即使斷電情況的方法是redis同步到磁盤方式保持默認的每秒，在redis無論因爲什麼原因停掉後要等待TTL時間後再重啓(學名:延遲重啓) ;缺點是 在TTL時間內服務相當於暫停狀態;
總結：
-
TTL時長 要大於正常業務執行的時間+獲取所有redis服務消耗時間+時鐘漂移
-
獲取redis所有服務消耗時間要 遠小於TTL時間，並且獲取成功的鎖個數要 在總數的一般以上:N/2+1
-
嘗試獲取每個redis實例鎖時的時間要 遠小於TTL時間
-
嘗試獲取所有鎖失敗後 重新嘗試一定要有一定次數限制
-
在redis崩潰後（無論一個還是所有），要延遲TTL時間重啓redis
-
在實現多redis節點時要結合單節點分佈式鎖算法 共同實現
查看代碼
思路
父進程其一個子進程，父進程監控子進程，子進程執行程序，父進程監控，一半的過期時間後，子進程存在，去續期鎖的有效期，子進程退出，釋放鎖
代碼尚未完善，需壓測，未完待續
https://github.com/zqlpaopao/-