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單實例中實現分布式鎖的正確方式（原子性非常重要）:
1.設置鎖時，使用set命令，因為其包含了setnx,expire的功能，起到了原子操作的效果，給key設置隨機值，并且只有在key不存在時才設置成功返回True,并且設置key的過期時間（最好用毫秒）
SET key_name my_random_value NX PX 30000 # NX 表示if not exist 就設置并返回True，否則不設置并返回False PX 表示過期時間用毫秒級， 30000 表示這些毫秒時間后此key過期
2.在獲取鎖后，并完成相關業務后，需要刪除自己設置的鎖（必須是只能刪除自己設置的鎖，不能刪除他人設置的鎖）；
刪除原因：保證服務器資源的高利用效率，不用等到鎖自動過期才刪除；
刪除方法：最好使用Lua腳本刪除（redis保證執行此腳本時不執行其他操作，保證操作的原子性），代碼如下；邏輯是 先獲取key，如果存在并且值是自己設置的就刪除此key;否則就跳過；
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
算法流程圖如下：
多節點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.重試獲取鎖要有一定次數限制
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分布式鎖 算法流程圖如下（不推薦使用）：
不推薦原因：
1.根據流程圖可看出其流程較為繁瑣
2.使用較為老式的 setnx方法獲取鎖及expire方法（無法保證原子操作）
3.redis單點，無法做到錯誤兼容性；
