參考鏈接：①Redis分布式鎖:單機Redis實現分布式鎖、Redission可重入鎖、Redission紅鎖機制(解決分布式redis單點宕機故障轉移存在的遺留問題)
問題
最近看一些redis分布式鎖的資料，大體思路都是一致，而且基本上都是用的Redission。
這個本身也沒啥問題，但是奇怪的是，在介紹分布式鎖的缺點時，總是千篇一律的介紹了一種異常情況，是分布式鎖redission無法處理的。具體發生的過程介紹如下：
1）redis的部署方式為一主多從
2）如果客戶端1給redis主節點加了分布式鎖，但是redis主節點在異步復制給從節點之前就掛了，導致分布式鎖丟失
3）某個從節點自動成為新的主節點后，因為同步鎖丟失的原因，並不知道客戶端1已經加鎖，這時客戶端2也來了加鎖行為，這時客戶端2自然加鎖成功！！！
問題的關鍵是，客戶端1沒有主動釋放鎖，也沒有因為過期而釋放鎖，這時客戶端2就能得到鎖，這不是很大的問題嗎？我們的分布式鎖，在這種情況下，不是失去意義了嗎？？？
完善辦法
我剛開始也覺得，基於這種情況，說的挺有道理，實在是無解，畢竟數據丟了，沒有辦法。
但是（注意我要開始ZB了），我覺得肯定會有其他解決方案，或者更進一步完善的方案，對不對？
果然，就發現了另一個神奇的東西：紅鎖（RedLock），redission里對應RedissonRedLock
紅鎖的關鍵思想：
1）加鎖時，嘗試給每個redis節點都加鎖
2）必須有超過一半的redis加鎖成功，才算本次加鎖成功（加鎖成功含義：成功獲取到鎖，且耗時時間小於鎖失效時間）
比如有1個主redis節點、4個從節點，那么總共有5個節點，紅鎖加鎖時，會同時往5個節點都加鎖，並且至少3個節點加鎖成功，才算最終加鎖成功。
如果加了紅鎖機制后，主從情況下，分布式鎖剛加完，主節點掛掉，那么新的從節點大概率會持有分布式鎖。
為什么會是大概率？因為可能當時紅鎖加鎖也成功了，但是其實5節點中，有一個從節點掛掉了，所以改從節點沒有分布式鎖，但是之后又被實施人員啟動了，這種時候，如果主節點掛掉，而剛啟動起來的從節點又剛好被作為新的主節點，那么還有會有問題。