Redlock：全名叫做 redis Distributed Lock;即使用redis實現(xiàn)的分布式鎖；
使用場景：多個服務(wù)間保證同一時刻同一時間段內(nèi)同一用戶只能有一個請求（防止關(guān)鍵業(yè)務(wù)出現(xiàn)并發(fā)攻擊）；
官網(wǎng)文檔地址如下：https://redis.io/topics/distlock
這個鎖的算法實現(xiàn)了多redis實例的情況，相對于單redis節(jié)點來說，優(yōu)點在于 防止了 單節(jié)點故障造成整個服務(wù)停止運行的情況；并且在多節(jié)點中鎖的設(shè)計，及多節(jié)點同時崩潰等各種意外情況有自己獨特的設(shè)計方法；
此博客或者官方文檔的相關(guān)概念：
1.TTL：Time To Live;只 redis key 的過期時間或有效生存時間
2.clock drift:時鐘漂移；指兩個電腦間時間流速基本相同的情況下，兩個電腦（或兩個進(jìn)程間）時間的差值；如果電腦距離過遠(yuǎn)會造成時鐘漂移值 過大
最低保證分布式鎖的有效性及安全性的要求如下：
1.互斥；任何時刻只能有一個client獲取鎖
2.釋放死鎖；即使鎖定資源的服務(wù)崩潰或者分區(qū)，仍然能釋放鎖
3.容錯性；只要多數(shù)redis節(jié)點（一半以上）在使用，client就可以獲取和釋放鎖
網(wǎng)上講的基于故障轉(zhuǎn)移實現(xiàn)的redis主從無法真正實現(xiàn)Redlock:
因為redis在進(jìn)行主從復(fù)制時是異步完成的，比如在clientA獲取鎖后，主redis復(fù)制數(shù)據(jù)到從redis過程中崩潰了，導(dǎo)致沒有復(fù)制到從redis中，然后從redis選舉出一個升級為主redis,造成新的主redis沒有clientA 設(shè)置的鎖，這是clientB嘗試獲取鎖，并且能夠成功獲取鎖，導(dǎo)致互斥失效；
思考題：這個失敗的原因是因為從redis立刻升級為主redis，如果能夠過TTL時間再升級為主redis（延遲升級）后，或者立刻升級為主redis但是過TTL的時間后再執(zhí)行獲取鎖的任務(wù)，就能成功產(chǎn)生互斥效果；是不是這樣就能實現(xiàn)基于redis主從的Redlock;
redis單實例中實現(xiàn)分布式鎖的正確方式（原子性非常重要）:
1.設(shè)置鎖時，使用set命令，因為其包含了setnx,expire的功能，起到了原子操作的效果，給key設(shè)置隨機值，并且只有在key不存在時才設(shè)置成功返回True,并且設(shè)置key的過期時間（最好用毫秒）
SET key_name my_random_value NX PX 30000 # NX 表示if not exist 就設(shè)置并返回True，否則不設(shè)置并返回False PX 表示過期時間用毫秒級， 30000 表示這些毫秒時間后此key過期
2.在獲取鎖后，并完成相關(guān)業(yè)務(wù)后，需要刪除自己設(shè)置的鎖（必須是只能刪除自己設(shè)置的鎖，不能刪除他人設(shè)置的鎖）；
刪除原因：保證服務(wù)器資源的高利用效率，不用等到鎖自動過期才刪除；
刪除方法：最好使用Lua腳本刪除（redis保證執(zhí)行此腳本時不執(zhí)行其他操作，保證操作的原子性），代碼如下；邏輯是 先獲取key，如果存在并且值是自己設(shè)置的就刪除此key;否則就跳過；
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
算法流程圖如下：
多節(jié)點redis實現(xiàn)的分布式鎖算法(RedLock):有效防止單點故障
假設(shè)有5個完全獨立的redis主服務(wù)器
1.獲取當(dāng)前時間戳
2.client嘗試按照順序使用相同的key,value獲取所有redis服務(wù)的鎖，在獲取鎖的過程中的獲取時間比鎖過期時間短很多，這是為了不要過長時間等待已經(jīng)關(guān)閉的redis服務(wù)。并且試著獲取下一個redis實例。
比如：TTL為5s,設(shè)置獲取鎖最多用1s，所以如果一秒內(nèi)無法獲取鎖，就放棄獲取這個鎖，從而嘗試獲取下個鎖
3.client通過獲取所有能獲取的鎖后的時間減去第一步的時間，這個時間差要小于TTL時間并且至少有3個redis實例成功獲取鎖，才算真正的獲取鎖成功
4.如果成功獲取鎖，則鎖的真正有效時間是 TTL減去第三步的時間差 的時間；比如：TTL 是5s,獲取所有鎖用了2s,則真正鎖有效時間為3s(其實應(yīng)該再減去時鐘漂移);
5.如果客戶端由于某些原因獲取鎖失敗，便會開始解鎖所有redis實例；因為可能已經(jīng)獲取了小于3個鎖，必須釋放，否則影響其他client獲取鎖
算法示意圖如下：
RedLock算法是否是異步算法？？
可以看成是同步算法；因為 即使進(jìn)程間（多個電腦間）沒有同步時鐘，但是每個進(jìn)程時間流速大致相同；并且時鐘漂移相對于TTL叫小，可以忽略，所以可以看成同步算法；（不夠嚴(yán)謹(jǐn)，算法上要算上時鐘漂移，因為如果兩個電腦在地球兩端，則時鐘漂移非常大）
RedLock失敗重試
當(dāng)client不能獲取鎖時，應(yīng)該在隨機時間后重試獲取鎖；并且最好在同一時刻并發(fā)的把set命令發(fā)送給所有redis實例；而且對于已經(jīng)獲取鎖的client在完成任務(wù)后要及時釋放鎖，這是為了節(jié)省時間；
RedLock釋放鎖
由于釋放鎖時會判斷這個鎖的value是不是自己設(shè)置的，如果是才刪除；所以在釋放鎖時非常簡單，只要向所有實例都發(fā)出釋放鎖的命令，不用考慮能否成功釋放鎖；
RedLock注意點（Safety arguments）:
1.先假設(shè)client獲取所有實例，所有實例包含相同的key和過期時間(TTL) ,但每個實例set命令時間不同導(dǎo)致不能同時過期，第一個set命令之前是T1,最后一個set命令后為T2,則此client有效獲取鎖的最小時間為TTL-(T2-T1)-時鐘漂移;
2.對于以N/2+ 1(也就是一半以 上)的方式判斷獲取鎖成功，是因為如果小于一半判斷為成功的話，有可能出現(xiàn)多個client都成功獲取鎖的情況， 從而使鎖失效
3.一個client鎖定大多數(shù)事例耗費的時間大于或接近鎖的過期時間，就認(rèn)為鎖無效，并且解鎖這個redis實例(不執(zhí)行業(yè)務(wù)) ;只要在TTL時間內(nèi)成功獲取一半以上的鎖便是有效鎖;否則無效
系統(tǒng)有活性的三個特征
1.能夠自動釋放鎖
2.在獲取鎖失?。ú坏揭话胍陨希?，或任務(wù)完成后 能夠自動釋放鎖，不用等到其自動過期
3.在client重試獲取哦鎖前（第一次失敗到第二次重試時間間隔）大于第一次獲取鎖消耗的時間；
4.重試獲取鎖要有一定次數(shù)限制
RedLock性能及崩潰恢復(fù)的相關(guān)解決方法
1.如果redis沒有持久化功能，在clientA獲取鎖成功后，所有redis重啟，clientB能夠再次獲取到鎖，這樣違法了鎖的排他互斥性;
2.如果啟動AOF永久化存儲，事情會好些， 舉例:當(dāng)我們重啟redis后，由于redis過期機制是按照unix時間戳走的，所以在重啟后，然后會按照規(guī)定的時間過期，不影響業(yè)務(wù);但是由于AOF同步到磁盤的方式默認(rèn)是每秒-次，如果在一秒內(nèi)斷電，會導(dǎo)致數(shù)據(jù)丟失，立即重啟會造成鎖互斥性失效;但如果同步磁盤方式使用Always(每一個寫命令都同步到硬盤)造成性能急劇下降;所以在鎖完全有效性和性能方面要有所取舍;
3.有效解決既保證鎖完全有效性及性能高效及即使斷電情況的方法是redis同步到磁盤方式保持默認(rèn)的每秒，在redis無論因為什么原因停掉后要等待TTL時間后再重啟(學(xué)名:延遲重啟) ;缺點是 在TTL時間內(nèi)服務(wù)相當(dāng)于暫停狀態(tài);
總結(jié)：
1.TTL時長 要大于正常業(yè)務(wù)執(zhí)行的時間+獲取所有redis服務(wù)消耗時間+時鐘漂移
2.獲取redis所有服務(wù)消耗時間要 遠(yuǎn)小于TTL時間，并且獲取成功的鎖個數(shù)要 在總數(shù)的一般以上:N/2+1
3.嘗試獲取每個redis實例鎖時的時間要 遠(yuǎn)小于TTL時間
4.嘗試獲取所有鎖失敗后 重新嘗試一定要有一定次數(shù)限制
5.在redis崩潰后（無論一個還是所有），要延遲TTL時間重啟redis
6.在實現(xiàn)多redis節(jié)點時要結(jié)合單節(jié)點分布式鎖算法 共同實現(xiàn)
網(wǎng)絡(luò)上查找的redis分布式鎖 算法流程圖如下（不推薦使用）：
不推薦原因：
1.根據(jù)流程圖可看出其流程較為繁瑣
2.使用較為老式的 setnx方法獲取鎖及expire方法（無法保證原子操作）
3.redis單點，無法做到錯誤兼容性；
