最基本的Jedis方案

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

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

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

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

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

　　客戶端獲取當(dāng)前時(shí)間戳，單位: 毫秒

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

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

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

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

　　過程?

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

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

　　互斥?

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

　　watch dog自動(dòng)延時(shí)機(jī)制?

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

　　可重入?

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

　　方案比較

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

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

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