利用Redis實現分散式鎖
寫在最前面
我在之前總結冪等性的時候，寫過一種分散式鎖的實現，可惜當時沒有真正應用過，著實的心虛啊。正好這段時間對這部分實踐了一下，也算是對之前填坑了。
分散式鎖按照網上的結論，大致分為三種：1、資料庫樂觀鎖； 2、基於Redis的分散式鎖；3.、基於ZooKeeper的分散式鎖；
關於樂觀鎖的實現其實在之前已經講的很清楚了，有興趣的移步： ofollow,noindex" target="_blank">使用mysql樂觀鎖解決併發問題 。今天先簡單總結下redis的實現方法，後面詳細研究過ZooKeeper的實現原理後再具體說說ZooKeeper的實現。
為什麼需要分散式鎖？
在傳統單體應用單機部署的情況下，可以使用Java併發相關的鎖，如ReentrantLcok或synchronized進行互斥控制。但是，隨著業務發展的需要，原單體單機部署的系統，漸漸的被部署在多機器多JVM上同時提供服務，這使得原單機部署情況下的併發控制鎖策略失效了，為了解決這個問題就需要一種跨JVM的互斥機制來控制共享資源的訪問，這就是分散式鎖要解決的問題。
分散式鎖的實現條件
1、互斥性，和單體應用一樣，要保證任意時刻，只能有一個客戶端持有鎖
2、可靠性，要保證系統的穩定性，不能產生死鎖
3、一致性，要保證鎖只能由加鎖人解鎖，不能產生A的加鎖被B使用者解鎖的情況
Redis分散式鎖的實現
Redis實現分散式鎖不同的人可能有不同的實現邏輯，但是核心就是下面三個方法。
SETNX
SETNX key val
當且僅當key不存在時，set一個key為val的字串，返回1；若key存在，則什麼都不做，返回0。
Expire
expire key timeout
為key設定一個超時時間，單位為second，超過這個時間鎖會自動釋放，避免死鎖。
Delete
delete key
刪除key
獲取鎖
首先講一個目前網上應用最多的一種實現
實現思路：
1.獲取鎖的時候，使用setnx加鎖，並使用expire命令為鎖新增一個超時時間，超過該時間則自動釋放鎖以免產生死鎖，鎖的value值為一個隨機生成的UUID，通過此在釋放鎖的時候進行判斷。
2.獲取鎖的時候還設定一個獲取的超時時間，若超過這個時間則放棄獲取鎖。
3.釋放鎖的時候，通過UUID判斷是不是該鎖，若是該鎖，則執行delete進行鎖釋放。
public String getRedisLock(Jedis jedis, String lockKey, Long acquireTimeout, Long timeOut) { try { // 定義 redis 對應key 的value值(uuid) 作用 釋放鎖 隨機生成value,根據專案情況修改 String identifierValue = UUID.randomUUID().toString(); // 定義在獲取鎖之後的超時時間 int expireLock = (int) (timeOut / 1000);// 以秒為單位 // 定義在獲取鎖之前的超時時間 //使用迴圈機制 如果沒有獲取到鎖，要在規定acquireTimeout時間 保證重複進行嘗試獲取鎖 // 使用迴圈方式重試的獲取鎖 Long endTime = System.currentTimeMillis() + acquireTimeout; while (System.currentTimeMillis() < endTime) { // 獲取鎖 // 使用setnx命令插入對應的redislockKey ，如果返回為1 成功獲取鎖 if (jedis.setnx(lockKey, identifierValue) == 1) { // 設定對應key的有效期 jedis.expire(lockKey, expireLock); return identifierValue; } } } catch (Exception e) { e.printStackTrace(); } return null; }
這種實現方法也是目前應用最多的實現，我一直以為這確實是正確的。然而由於這是兩條Redis命令，不具有原子性，如果程式在執行完setnx()之後突然崩潰，導致鎖沒有設定過期時間。那麼還是會發生死鎖的情況。網上之所以有人這樣實現，是因為低版本的jedis並不支援多引數的set()方法。
當然這種情況Jedis的設計者也顯然想到了，新版的Jedis可以同時set多個引數，具體實現如下：
實現思路：
基本上和原來的邏輯類似，只是將setnx和expire的操作合併為一步，改為使用新的set多參的方法。
set(final String key, final String value, final String nxxx, final String expx,final long time)
key和value自然不用多說。nxxx引數只可以傳String 型別的NX（僅在不存在的情況下設定）和XX（和普通的set操作一樣會做更新操作）兩種。
expx是指到期時間單位，可傳引數為EX （秒）和 PX （毫秒）,time就是具體的過期時間了，單位為前面expx所指定的。
然後我們對上面的程式碼進行改造如下：
/**
* @param acquireTimeout
*在獲取鎖之前的超時時間
* @param timeOut
*在獲取鎖之後的超時時間
*/
public String getRedisLock(Jedis jedis, String lockKey, Long acquireTimeout, Long timeOut) {
try {
// 定義 redis 對應key 的value值(uuid) 作用 釋放鎖 隨機生成value,根據專案情況修改
String identifierValue = UUID.randomUUID().toString();
// 定義在獲取鎖之前的超時時間
//使用迴圈機制 如果沒有獲取到鎖，要在規定acquireTimeout時間 保證重複進行嘗試獲取鎖
// 使用迴圈方式重試的獲取鎖
Long endTime = System.currentTimeMillis() + acquireTimeout;
while (System.currentTimeMillis() < endTime) {
// 獲取鎖
// set使用NX引數的方式就等同於 setnx()方法，成功返回OK.PX以毫秒為單位
if ("OK".equals(jedis.set(lockKey, lockKey, "NX", "PX", timeOut))) {
return identifierValue;
}
}
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
好了，獲取鎖的操作基本上就上面這些，有同學可能要問，為什麼不直接返回一個Boolean型的true或false呢？
正如我前面所說的，要保證解鎖的一致性，所以就需要通過value值來保證解鎖人就是加鎖人，而不能直接返回true或false了。
下面在說下解鎖的過程。
釋放鎖
還是先舉一個錯誤的例子：
實現思路：
釋放鎖的時候，通過傳入key和加鎖時返回的value值，判斷傳入的value是否和key從redis中取出的相等。相等則證明解鎖人就是加鎖人，執行delete釋放鎖的操作。
// 釋放redis鎖
public void unRedisLock(Jedis jedis, String lockKey, String identifierValue) {
try {
// 如果該鎖的id 等於identifierValue 是同一把鎖情況才可以刪除
if (jedis.get(lockKey).equals(identifierValue)) {
jedis.del(lockKey);
}
} catch (Exception e){
e.printStackTrace();
}
}
看著好像沒啥問題哈。然而仔細想想又總感覺哪裡不對。
如果在執行jedis.del(lockKey)操作之前，剛好鎖的過期時間到了，而這個時候又有別的客戶端取到了鎖，我們在此時執行刪除操作，不是又不符合一致性的要求了嗎。
然後我們修改為下述方案：
修改後的程式碼為：
public void unRedisLock(Jedis jedis, String lockKey, String identifierValue) {
try {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Long result = (Long) jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(identifierValue));
//0釋放鎖失敗。1釋放成功
if (1 == result) {
//如果你想返回刪除成功還是失敗，可以在這裡返回
System.out.println(result+"釋放鎖成功");
}
if (0 == result){
System.out.println(result+"釋放鎖失敗");
}
} catch (Exception e){
e.printStackTrace();
}
}
實現思路：
我們將Lua程式碼傳到jedis.eval()方法裡，並使引數KEYS[1]賦值為lockKey，ARGV[1]賦值為identifierValue。eval()方法是將Lua程式碼交給Redis服務端執行。
那麼這段Lua程式碼的功能是什麼呢？其實很簡單，首先獲取鎖對應的value值，檢查是否與identifierValue相等，如果相等則刪除鎖（解鎖）。那麼為什麼要使用Lua語言來實現呢？因為要確保上述操作是原子性的。
那麼為什麼執行eval()方法可以確保原子性？源於Redis的特性，因為Redis是單執行緒，在eval命令執行Lua程式碼的時候，Lua程式碼將被當成一個命令去執行，並且直到eval命令執行完成，Redis才會執行其他命令。
總結
本文對Redis實現分散式鎖做了比較詳細的總結。我個人也對上述程式碼做了實踐檢驗。其實我在使用時，一直用的錯誤的案例。直到看到園友Ruthless的一篇文章才曉得稀疏平常的寫法竟然漏洞百出，感謝部落格園，感謝Ruthless。下一篇準備再研究研究ZooKeeper的實現。
最後附上Ruthless的原文連結：https://www.cnblogs.com/linjiqin/p/8003838.html