共計 5260 個字符，預計需要花費 14 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
這篇文章給大家分享的是有關 Redis 分布式鎖怎么實現的內容。丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，一起跟隨丸趣 TV 小編過來看看吧。
分布式鎖一般有三種實現方式：
1、數據庫樂觀鎖；
2、基于 Redis 的分布式鎖；
3、基于 ZooKeeper 的分布式鎖。
本文將介紹第二種方式，基于 Redis 實現分布式鎖。雖然網上已經有各種介紹 Redis 分布式鎖實現的博客，然而他們的實現卻有著各種各樣的問題，為了避免誤人子弟，本篇博客將詳細介紹如何正確地實現 Redis 分布式鎖。
可靠性
首先，為了確保分布式鎖可用，我們至少要確保鎖的實現同時滿足以下四個條件：
1、互斥性。在任意時刻，只有一個客戶端能持有鎖。
2、不會發生死鎖。即使有一個客戶端在持有鎖的期間崩潰而沒有主動解鎖，也能保證后續其他客戶端能加鎖。
3、具有容錯性。只要大部分的 Redis 節點正常運行，客戶端就可以加鎖和解鎖。
4、解鈴還須系鈴人。加鎖和解鎖必須是同一個客戶端，客戶端自己不能把別人加的鎖給解了。
代碼實現
組件依賴
首先我們要通過 Maven 引入 Jedis 開源組件，在 pom.xml 文件加入下面的代碼：
dependency
groupId redis.clients /groupId
artifactId jedis /artifactId
version 2.9.0 /version
/dependency加鎖代碼
正確姿勢
Talk is cheap, show me the code。先展示代碼，再帶大家慢慢解釋為什么這樣實現：
public class RedisTool {
private static final String LOCK_SUCCESS = OK
private static final String SET_IF_NOT_EXIST = NX
private static final String SET_WITH_EXPIRE_TIME = PX
/**
* 嘗試獲取分布式鎖
* @param jedis Redis 客戶端
* @param lockKey 鎖
* @param requestId 請求標識
* @param expireTime 超期時間
* @return 是否獲取成功
*/
public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {
String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);
if (LOCK_SUCCESS.equals(result)) {
return true;
}
return false;
}
}可以看到，我們加鎖就一行代碼：jedis.set(String key, String value, String nxxx, String expx, int time)，這個 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. 已有鎖存在，不做任何操作。
心細的童鞋就會發現了，我們的加鎖代碼滿足我們可靠性里描述的三個條件：
1、首先，set() 加入了 NX 參數，可以保證如果已有 key 存在，則函數不會調用成功，也就是只有一個客戶端能持有鎖，滿足互斥性。
2、其次，由于我們對鎖設置了過期時間，即使鎖的持有者后續發生崩潰而沒有解鎖，鎖也會因為到了過期時間而自動解鎖（即 key 被刪除），不會發生死鎖。
3、最后，因為我們將 value 賦值為 requestId，代表加鎖的客戶端請求標識，那么在客戶端在解鎖的時候就可以進行校驗是否是同一個客戶端。由于我們只考慮 Redis 單機部署的場景，所以容錯性我們暫不考慮。
錯誤示例 1
比較常見的錯誤示例就是使用 jedis.setnx() 和 jedis.expire() 組合實現加鎖，代碼如下：
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() 方法作用就是 SET IF NOT EXIST，expire() 方法就是給鎖加一個過期時間。乍一看好像和前面的 set() 方法結果一樣，然而由于這是兩條 Redis 命令，不具有原子性，如果程序在執行完 setnx() 之后突然崩潰，導致鎖沒有設置過期時間。那么將會發生死鎖。網上之所以有人這樣實現，是因為低版本的 jedis 并不支持多參數的 set() 方法。
錯誤示例 2
public static boolean wrongGetLock2(Jedis jedis, String lockKey, int expireTime) {
long expires = System.currentTimeMillis() + expireTime;
String expiresStr = String.valueOf(expires);
// 如果當前鎖不存在，返回加鎖成功
if (jedis.setnx(lockKey, expiresStr) == 1) {
return true;
}
// 如果鎖存在，獲取鎖的過期時間
String currentValueStr = jedis.get(lockKey);
if (currentValueStr != null Long.parseLong(currentValueStr) System.currentTimeMillis()) {
// 鎖已過期，獲取上一個鎖的過期時間，并設置現在鎖的過期時間
String oldValueStr = jedis.getSet(lockKey, expiresStr);
if (oldValueStr != null oldValueStr.equals(currentValueStr)) {
// 考慮多線程并發的情況，只有一個線程的設置值和當前值相同，它才有權利加鎖
return true;
}
}
// 其他情況，一律返回加鎖失敗
return false;
}這一種錯誤示例就比較難以發現問題，而且實現也比較復雜。實現思路：使用 jedis.setnx() 命令實現加鎖，其中 key 是鎖，value 是鎖的過期時間。
執行過程：
1、通過 setnx() 方法嘗試加鎖，如果當前鎖不存在，返回加鎖成功。
2、如果鎖已經存在則獲取鎖的過期時間，和當前時間比較，如果鎖已經過期，則設置新的過期時間，返回加鎖成功。代碼如下：
那么這段代碼問題在哪里？
1、由于是客戶端自己生成過期時間，所以需要強制要求分布式下每個客戶端的時間必須同步。
2、當鎖過期的時候，如果多個客戶端同時執行 jedis.getSet() 方法，那么雖然最終只有一個客戶端可以加鎖，但是這個客戶端的鎖的過期時間可能被其他客戶端覆蓋。
3、鎖不具備擁有者標識，即任何客戶端都可以解鎖。
解鎖代碼
正確姿勢
還是先展示代碼，再帶大家慢慢解釋為什么這樣實現：
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 lockKey, 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;
}
}可以看到，我們解鎖只需要兩行代碼就搞定了！第一行代碼，我們寫了一個簡單的 Lua 腳本代碼，上一次見到這個編程語言還是在《黑客與畫家》里，沒想到這次居然用上了。第二行代碼，我們將 Lua 代碼傳到 jedis.eval() 方法里，并使參數 KEYS[1] 賦值為 lockKey，ARGV[1] 賦值為 requestId。eval() 方法是將 Lua 代碼交給 Redis 服務端執行。
那么這段 Lua 代碼的功能是什么呢？其實很簡單，首先獲取鎖對應的 value 值，檢查是否與 requestId 相等，如果相等則刪除鎖（解鎖）。那么為什么要使用 Lua 語言來實現呢？因為要確保上述操作是原子性的。關于非原子性會帶來什么問題，可以閱讀【解鎖代碼 - 錯誤示例 2】。
那么為什么執行 eval() 方法可以確保原子性，源于 Redis 的特性，下面是官網對 eval 命令的部分解釋：
簡單來說，就是在 eval 命令執行 Lua 代碼的時候，Lua 代碼將被當成一個命令去執行，并且直到 eval 命令執行完成，Redis 才會執行其他命令。
錯誤示例 1
最常見的解鎖代碼就是直接使用 jedis.del() 方法刪除鎖，這種不先判斷鎖的擁有者而直接解鎖的方式，會導致任何客戶端都可以隨時進行解鎖，即使這把鎖不是它的。
public static void wrongReleaseLock1(Jedis jedis, String lockKey) { jedis.del(lockKey);
}錯誤示例 2
這種解鎖代碼乍一看也是沒問題，甚至我之前也差點這樣實現，與正確姿勢差不多，唯一區別的是分成兩條命令去執行，代碼如下：
public static void wrongReleaseLock2(Jedis jedis, String lockKey, String requestId) {
// 判斷加鎖與解鎖是不是同一個客戶端
if (requestId.equals(jedis.get(lockKey))) {
// 若在此時，這把鎖突然不是這個客戶端的，則會誤解鎖
jedis.del(lockKey);
}
}如代碼注釋，問題在于如果調用 jedis.del() 方法的時候，這把鎖已經不屬于當前客戶端的時候會解除他人加的鎖。那么是否真的有這種場景？答案是肯定的，比如客戶端 A 加鎖，一段時間之后客戶端 A 解鎖，在執行 jedis.del() 之前，鎖突然過期了，此時客戶端 B 嘗試加鎖成功，然后客戶端 A 再執行 del() 方法，則將客戶端 B 的鎖給解除了。
感謝各位的閱讀！關于“Redis 分布式鎖怎么實現”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！
向 AI 問一下細節
