redis分散式鎖及會出現的問題解決
一、redis實現分散式鎖的主要原理：
1.加鎖
最簡單的方法是使用setnx命令。key是鎖的唯一標識，按業務來決定命名。比如想要給一種商品的秒殺活動加鎖，可以給key命名為 “lock_sale_商品ID” 。而value設定成什麼呢？我們可以姑且設定成1。加鎖的虛擬碼如下：
setnx（key，1）
當一個執行緒執行setnx返回1，說明key原本不存在，該執行緒成功得到了鎖；當一個執行緒執行setnx返回0，說明key已經存在，該執行緒搶鎖失敗。
2.解鎖
有加鎖就得有解鎖。當得到鎖的執行緒執行完任務，需要釋放鎖，以便其他執行緒可以進入。釋放鎖的最簡單方式是執行del指令，虛擬碼如下：
del（key）
釋放鎖之後，其他執行緒就可以繼續執行setnx命令來獲得鎖。
3.鎖超時
鎖超時是什麼意思呢？如果一個得到鎖的執行緒在執行任務的過程中掛掉，來不及顯式地釋放鎖，這塊資源將會永遠被鎖住，別的執行緒再也別想進來。
所以，setnx的key必須設定一個超時時間，以保證即使沒有被顯式釋放，這把鎖也要在一定時間後自動釋放。setnx不支援超時引數，所以需要額外的指令，虛擬碼如下：
expire（key， 30）
二、加鎖的程式碼
/**
* 嘗試獲取分散式鎖
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請求標識
* @param expireTime 超期時間
* @return 是否獲取成功
*/
public static void wrongGetLock1(Jedis jedis,String lockKey,String requestId,int expireTime) {
Long result = jedis.setnx(lockKey,requestId);
if (result == 1) {
// 若在這裡程式突然崩潰，則無法設定過期時間，將發生死鎖
jedis.expire(lockKey,expireTime);
}
}上面的程式碼有一個致命的問題，就是加鎖和設定過期時間不是原子操作。
那麼會有兩種極端情況：
一種是在併發情況下，兩個執行緒同時執行setnx，那麼得到的結果都是1，這樣兩個執行緒同時拿到了鎖。
別一種是如程式碼註釋所示，即執行完setnx，程式崩潰沒有執行過期時間，那這把鎖就永遠不會被釋放，造成了死鎖。
之所以有人這樣實現，是因為低版本的jedis並不支援多引數的set()方法。正確的程式碼如下：
/**
* 嘗試獲取分散式鎖
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請求標識
* @param expireTime 超期時間
* @return 是否獲取成功
*/
public static boolean tryGetDistributedLock(Jedis jedis,int expireTime) {
String result = jedis.set(lockKey,requestId,"NX","PX",expireTime);
if ("OK".equals(result)) {
return true;
}
return false;
}這個set()方法一共有五個形參：
第一個為key，我們使用key來當鎖，因為key是唯一的。
第二個為value，我們傳的是requestId，很多童鞋可能不明白，有key作為鎖不就夠了嗎，為什麼還要用到value？原因就是，通過給value賦值為requestId，我們就知道這把鎖是哪個請求加的了，在解鎖的時候就可以有依據。requestId可以使用UUID.randomUUID().toString()方法生成。
第三個為nxxx，這個引數我們填的是NX，意思是SET IF NOT EXIST，即當key不存在時，我們進行set操作；若key已經存在，則不做任何操作；
第四個為expx，這個引數我們傳的是PX，意思是我們要給這個key加一個過期的設定，具體時間由第五個引數決定。
第五個為time，與第四個引數相呼應，代表key的過期時間。
總的來說，執行上面的set()方法就只會導致兩種結果：1. 當前沒有鎖（key不存在），那麼就進行加鎖操作，並對鎖設定個有效期，同時value表示加鎖的客戶端。2. 已有鎖存在，不做任何操作。
二、解鎖的程式碼
public static void wrongReleaseLock1(Jedis jedis,String lockKey) {
jedis.del(lockKey);
}
這段程式碼的問題是容易導致誤刪，假如某執行緒成功得到了鎖，並且設定的超時時間是30秒。如果某些原因導致執行緒A執行的很慢很慢，過了30秒都沒執行完，這時候鎖過期自動釋放，執行緒B得到了鎖。
隨後，執行緒A執行完了任務，執行緒A接著執行del指令來釋放鎖。但這時候執行緒B還沒執行完，執行緒A實際上刪除的是執行緒B加的鎖。
怎麼避免這種情況呢？可以在del釋放鎖之前做一個判斷，驗證當前的鎖是不是自己加的鎖。
至於具體的實現，可以在加鎖的時候把當前的執行緒ID當做value，並在刪除之前驗證key對應的value是不是自己執行緒的ID。
public static void wrongReleaseLock2(Jedis jedis,String requestId) {
// 判斷加鎖與解鎖是不是同一個客戶端
if (requestId.equals(jedis.get(lockKey))) {
// 若在此時，這把鎖突然不是這個客戶端的，則會誤解鎖
jedis.del(lockKey);
}
}
但是，這樣做又隱含了一個新的問題，判斷和釋放鎖是兩個獨立操作，不是原子性。
解決方案就是使用lua指令碼，把它變成原子操作，程式碼如下：
public class RedisTool {
private static final Long RELEASE_SUCCESS = 1L;
/**
* 釋放分散式鎖
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請求標識
* @return 是否釋放成功
*/
public static boolean releaseDistributedLock(Jedis jedis,String requestId) {
String script = "if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end";
Object result = jedis.eval(script,Collections.singletonList(lockKey),Collections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
}
}
三、續約問題
上面加鎖最後的程式碼就完美了嗎？假想這樣一個場景，如果過期時間為30S，A執行緒超過30S還沒執行完，但是自動過期了。這時候B執行緒就會再拿到鎖，造成了同時有兩個執行緒持有鎖。這個問題可以歸結為”續約“問題，即A沒執行完時應該過期時間續約，執行完成才能釋放鎖。怎麼辦呢？我們可以讓獲得鎖的執行緒開啟一個守護執行緒，用來給快要過期的鎖“續約”。
其實，後面解鎖出現的刪除非自己鎖，也屬於“續約”問題。
四、叢集同步延遲問題
用於redis的服務肯定不能是單機，因為單機就不是高可用了，一量掛掉整個分散式鎖就沒用了。
在叢集場景下，如果A在master拿到了鎖,在沒有把資料同步到slave時，master掛掉了。B再拿鎖就會從slave拿鎖，而且會拿到。又出現了兩個執行緒同時拿到鎖。
基於以上的考慮，Redis 的作者也考慮到這個問題，他提出了一個 RedLock 的演算法。
這個演算法的意思大概是這樣的：假設 Redis 的部署模式是 Redis Cluster，總共有 5 個 Master 節點。
通過以下步驟獲取一把鎖：
- 獲取當前時間戳，單位是毫秒。
- 輪流嘗試在每個 Master 節點上建立鎖，過期時間設定較短，一般就幾十毫秒。
- 嘗試在大多數節點上建立一個鎖，比如 5 個節點就要求是 3 個節點（n / 2 +1）。
- 客戶端計算建立好鎖的時間，如果建立鎖的時間小於超時時間，就算建立成功了。
- 要是鎖建立失敗了，那麼就依次刪除這個鎖。
- 只要別人建立了一把分散式鎖，你就得不斷輪詢去嘗試獲取鎖。
但是這樣的這種演算法還是頗具爭議的，可能還會存在不少的問題，無法保證加鎖的過程一定正確。
這個問題的根本原因就是redis的叢集屬於AP，分散式鎖屬於CP，用AP去實現CP是不可能的。
五、Redisson
Redisson是架設在Redis基礎上的一個Java駐記憶體資料網格（In-Memory Data Grid）。充分的利用了Redis鍵值資料庫提供的一系列優勢，基於Java實用工具包中常用介面，為使用者提供了一系列具有分散式特性的常用工具類。
Redisson通過lua指令碼解決了上面的原子性問題，通過“看門狗”解決了續約問題，但是它應該解決不了叢集中的同步延遲問題。
總結
redis分散式鎖的方案，無論用何種方式實現都會有續約問題與叢集同步延遲問題。總的來說，是一個不太靠譜的方案。如果追求高正確率，不能採用這種方案。
但是它也有優點，就是比較簡單，在某些非嚴格要求的場景是可以使用的，比如社交系統一類，交易系統一類不能出現重複交易則不建議用。
到此這篇關於redis分散式鎖及會出現的問題解決的文章就介紹到這了,更多相關redis分散式鎖內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！