寫在最前面

我在之前總結冪等性的時候，寫過一種分佈式鎖的實現，可惜當時沒有真正應用過，著實的心虛啊。正好這段時間對這部分實踐了一下，也算是對之前填坑了。

分佈式鎖按照網上的結論，大致分為三種：1、數據庫樂觀鎖； 2、基於Redis的分佈式鎖；3.、基於ZooKeeper的分佈式鎖；

關於樂觀鎖的實現其實在之前已經講的很清楚了，有興趣的移步：使用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/> 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 分佈式 心虛