最基本的Jedis方案

　　加鎖： set NX PX + 重試 + 重試間隔

　　向Redis發(fā)起如下命令: SET productId:lock 0xx9p03001 NX PX 30000 其中，"productId"由自己定義，可以是與本次業(yè)務(wù)有關(guān)的id，"0xx9p03001"是一串隨機值，必須保證全局唯一(原因在后文中會提到)，“NX"指的是當且僅當key(也就是案例中的"productId:lock”)在Redis中不存在時，返回執(zhí)行成功，否則執(zhí)行失敗。"PX 30000"指的是在30秒后，key將被自動刪除。執(zhí)行命令后返回成功，表明服務(wù)成功的獲得了鎖。

　　解鎖： 采用lua腳本： 在刪除key之前，一定要判斷服務(wù)A持有的value與Redis內(nèi)存儲的value是否一致。如果貿(mào)然使用服務(wù)A持有的key來刪除鎖，則會誤將服務(wù)B的鎖釋放掉。

　　基于RedLock實現(xiàn)分布式鎖

　　假設(shè)有兩個服務(wù)A、B都希望獲得鎖，有一個包含了5個redis master的Redis Cluster，執(zhí)行過程大致如下:

　　客戶端獲取當前時間戳，單位: 毫秒

　　服務(wù)A輪尋每個master節(jié)點，嘗試創(chuàng)建鎖。(這里鎖的過期時間比較短，一般就幾十毫秒) RedLock算法會嘗試在大多數(shù)節(jié)點上分別創(chuàng)建鎖，假如節(jié)點總數(shù)為n，那么大多數(shù)節(jié)點指的是n/2+1。

　　客戶端計算成功建立完鎖的時間，如果建鎖時間小于超時時間，就可以判定鎖創(chuàng)建成功。如果鎖創(chuàng)建失敗，則依次(遍歷master節(jié)點)刪除鎖。

　　只要有其它服務(wù)創(chuàng)建過分布式鎖，那么當前服務(wù)就必須輪尋嘗試獲取鎖。

　　基于Redisson實現(xiàn)分布式鎖?

　　過程?

　　線程去獲取鎖，獲取成功: 執(zhí)行l(wèi)ua腳本，保存數(shù)據(jù)到redis數(shù)據(jù)庫。

　　線程去獲取鎖，獲取失敗: 訂閱了解鎖消息，然后再嘗試獲取鎖，獲取成功后，執(zhí)行l(wèi)ua腳本，保存數(shù)據(jù)到redis數(shù)據(jù)庫。

　　互斥?

　　如果這個時候客戶端B來嘗試加鎖，執(zhí)行了同樣的一段lua腳本。個if判斷會執(zhí)行“exists myLock”，發(fā)現(xiàn)myLock這個鎖key已經(jīng)存在。接著第二個if判斷，判斷myLock鎖key的hash數(shù)據(jù)結(jié)構(gòu)中，是否包含客戶端B的ID，但明顯沒有，那么客戶端B會獲取到pttl myLock返回的一個數(shù)字，代表myLock這個鎖key的剩余生存時間。此時客戶端B會進入一個while循環(huán)，不聽的嘗試加鎖。

　　watch dog自動延時機制?

　　客戶端A加鎖的鎖key默認生存時間只有30秒，如果超過了30秒，客戶端A還想一直持有這把鎖，怎么辦?其實只要客戶端A一旦加鎖成功，就會啟動一個watch dog看門狗，它是一個后臺線程，會每隔10秒檢查一下，如果客戶端A還持有鎖key，那么就會不斷的延長鎖key的生存時間。

　　可重入?

　　每次lock會調(diào)用incrby，每次unlock會減一。

　　方案比較

　　1.借助Redis實現(xiàn)分布式鎖時，有一個共同的缺陷: 當獲取鎖被決絕后，需要不斷的循環(huán)，重新發(fā)送獲取鎖(創(chuàng)建key)的請求，直到請求成功。這就造成空轉(zhuǎn)，浪費寶貴的CPU資源。

　　2.RedLock算法本身有爭議，并不能保證健壯性。

　　3.Redisson實現(xiàn)分布式鎖時，除了將key新增到某個指定的master節(jié)點外，還需要由master自動異步的將key和value等數(shù)據(jù)同步至綁定的slave節(jié)點上。那么問題來了，如果master沒來得及同步數(shù)據(jù)，突然發(fā)生宕機，那么通過故障轉(zhuǎn)移和主備切換，slave節(jié)點被迅速升級為master節(jié)點，新的客戶端加鎖成功，舊的客戶端的watch dog發(fā)現(xiàn)key存在，誤以為舊客戶端仍然持有這把鎖，這就導(dǎo)致同時存在多個客戶端持有同名鎖的問題了。