寫在最前面
我在之前總結冪等性的時候，寫過一種分布式鎖的實現，可惜當時沒有真正應用過，着實的心虛啊。正好這段時間對這部分實踐了一下，也算是對之前填坑了。
分布式鎖按照網上的結論，大致分為三種：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 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。編碼是在現實生活中最容易產生成就感的工作，在學習過程中更要時刻保持着質疑精神，多思考多驗證。
最后附上Ruthless的原文鏈接：https://www.cnblogs.com/linjiqin/p/8003838.html