老大吩咐的可重入分布式鎖，終于實(shí)現(xiàn)了~

作者：樓下小黑哥 2020-06-15 08:15:47

開發(fā)

后端

分布式 最近在做一個(gè)項(xiàng)目，將一個(gè)其他公司的實(shí)現(xiàn)系統(tǒng)(下文稱作舊系統(tǒng))，完整的整合到自己公司的系統(tǒng)(下文稱作新系統(tǒng))中，這其中需要將對(duì)方實(shí)現(xiàn)的功能完整在自己系統(tǒng)也實(shí)現(xiàn)一遍。

創(chuàng)新互聯(lián)公司是一家專業(yè)提供高港企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、成都h5網(wǎng)站建設(shè)、小程序制作等業(yè)務(wù)。10年已為高港眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站設(shè)計(jì)公司優(yōu)惠進(jìn)行中。

本文轉(zhuǎn)載自微信公眾號(hào)「程序通事」，作者樓下小黑哥  。轉(zhuǎn)載本文請(qǐng)聯(lián)系程序通事公眾號(hào)。

重做永遠(yuǎn)比改造簡(jiǎn)單

最近在做一個(gè)項(xiàng)目，將一個(gè)其他公司的實(shí)現(xiàn)系統(tǒng)(下文稱作舊系統(tǒng))，完整的整合到自己公司的系統(tǒng)(下文稱作新系統(tǒng))中，這其中需要將對(duì)方實(shí)現(xiàn)的功能完整在自己系統(tǒng)也實(shí)現(xiàn)一遍。

舊系統(tǒng)還有一批存量商戶，為了不影響存量商戶的體驗(yàn)，新系統(tǒng)提供的對(duì)外接口，還必須得跟以前一致。最后系統(tǒng)完整切換之后，功能只運(yùn)行在新系統(tǒng)中，這就要求舊系統(tǒng)的數(shù)據(jù)還需要完整的遷移到新系統(tǒng)中。

當(dāng)然這些在做這個(gè)項(xiàng)目之前就有預(yù)期，想過這個(gè)過程很難，但是沒想到有那么難。原本感覺排期大半年，時(shí)間還是挺寬裕，現(xiàn)在感覺就是大坑，還不得不在坑里一點(diǎn)點(diǎn)去填。

哎，說多都是淚，不吐槽了，等到下次做完再給大家復(fù)盤下真正心得體會(huì)。

回到正文，上篇文章Redis 分布式鎖，咱們基于 Redis 實(shí)現(xiàn)一個(gè)分布式鎖。這個(gè)分布式鎖基本功能沒什么問題，但是缺少可重入的特性，所以這篇文章小黑哥就帶大家來實(shí)現(xiàn)一下可重入的分布式鎖。

本篇文章將會(huì)涉及以下內(nèi)容：

• 可重入
• 基于 ThreadLocal 實(shí)現(xiàn)方案
• 基于 Redis Hash 實(shí)現(xiàn)方案

可重入

說到可重入鎖，首先我們來看看一段來自 wiki 上可重入的解釋：

“若一個(gè)程序或子程序可以“在任意時(shí)刻被中斷然后操作系統(tǒng)調(diào)度執(zhí)行另外一段代碼，這段代碼又調(diào)用了該子程序不會(huì)出錯(cuò)”，則稱其為可重入(reentrant或re-entrant)的。即當(dāng)該子程序正在運(yùn)行時(shí)，執(zhí)行線程可以再次進(jìn)入并執(zhí)行它，仍然獲得符合設(shè)計(jì)時(shí)預(yù)期的結(jié)果。與多線程并發(fā)執(zhí)行的線程安全不同，可重入強(qiáng)調(diào)對(duì)單個(gè)線程執(zhí)行時(shí)重新進(jìn)入同一個(gè)子程序仍然是安全的。

當(dāng)一個(gè)線程執(zhí)行一段代碼成功獲取鎖之后，繼續(xù)執(zhí)行時(shí)，又遇到加鎖的代碼，可重入性就就保證線程能繼續(xù)執(zhí)行，而不可重入就是需要等待鎖釋放之后，再次獲取鎖成功，才能繼續(xù)往下執(zhí)行。

用一段 Java 代碼解釋可重入：

  
 
 
 

   
  
  
  
public synchronized void a() {
   
  
  
  
    b();
   
  
  
  
}
   
  
  
  

   
  
  
  
public synchronized void b() {
   
  
  
  
    // pass
   
  
  
  
}
  
 
 
 

假設(shè) X 線程在 a 方法獲取鎖之后，繼續(xù)執(zhí)行 b 方法，如果此時(shí)不可重入，線程就必須等待鎖釋放，再次爭(zhēng)搶鎖。

鎖明明是被 X 線程擁有，卻還需要等待自己釋放鎖，然后再去搶鎖，這看起來就很奇怪，我釋放我自己~

可重入性就可以解決這個(gè)尷尬的問題，當(dāng)線程擁有鎖之后，往后再遇到加鎖方法，直接將加鎖次數(shù)加 1，然后再執(zhí)行方法邏輯。退出加鎖方法之后，加鎖次數(shù)再減 1，當(dāng)加鎖次數(shù)為 0 時(shí)，鎖才被真正的釋放。

可以看到可重入鎖最大特性就是計(jì)數(shù)，計(jì)算加鎖的次數(shù)。所以當(dāng)可重入鎖需要在分布式環(huán)境實(shí)現(xiàn)時(shí)，我們也就需要統(tǒng)計(jì)加鎖次數(shù)。

分布式可重入鎖實(shí)現(xiàn)方式有兩種：

• 基于 ThreadLocal 實(shí)現(xiàn)方案
• 基于 Redis Hash 實(shí)現(xiàn)方案

首先我們看下基于 ThreadLocal 實(shí)現(xiàn)方案。

基于 ThreadLocal 實(shí)現(xiàn)方案

實(shí)現(xiàn)方式

Java 中 ThreadLocal可以使每個(gè)線程擁有自己的實(shí)例副本，我們可以利用這個(gè)特性對(duì)線程重入次數(shù)進(jìn)行計(jì)數(shù)。

下面我們定義一個(gè)ThreadLocal的全局變量 LOCKS，內(nèi)存存儲(chǔ) Map 實(shí)例變量。

  
 
 
 

   
  
  
  
private static ThreadLocal> LOCKS = ThreadLocal.withInitial(HashMap::new);
  
 
 
 

每個(gè)線程都可以通過 ThreadLocal獲取自己的 Map實(shí)例，Map 中 key 存儲(chǔ)鎖的名稱，而 value存儲(chǔ)鎖的重入次數(shù)。

加鎖的代碼如下：

  
 
 
 

   
  
  
  
/**
   
  
  
  
 * 可重入鎖
   
  
  
  
 *
   
  
  
  
 * @param lockName  鎖名字,代表需要爭(zhēng)臨界資源
   
  
  
  
 * @param request   唯一標(biāo)識(shí)，可以使用 uuid，根據(jù)該值判斷是否可以重入
   
  
  
  
 * @param leaseTime 鎖釋放時(shí)間
   
  
  
  
 * @param unit      鎖釋放時(shí)間單位
   
  
  
  
 * @return
   
  
  
  
 */
   
  
  
  
public Boolean tryLock(String lockName, String request, long leaseTime, TimeUnit unit) {
   
  
  
  
    Map counts = LOCKS.get();
   
  
  
  
    if (counts.containsKey(lockName)) {
   
  
  
  
        counts.put(lockName, counts.get(lockName) + 1);
   
  
  
  
        return true;
   
  
  
  
    } else {
   
  
  
  
        if (redisLock.tryLock(lockName, request, leaseTime, unit)) {
   
  
  
  
            counts.put(lockName, 1);
   
  
  
  
            return true;
   
  
  
  
        }
   
  
  
  
    }
   
  
  
  
    return false;
   
  
  
  
}
  
 
 
 

“ps: redisLock#tryLock 為上一篇文章實(shí)現(xiàn)的分布鎖。由于公號(hào)外鏈無法直接跳轉(zhuǎn)，關(guān)注『程序通事』，回復(fù)分布式鎖獲取源代碼。

加鎖方法首先判斷當(dāng)前線程是否已經(jīng)已經(jīng)擁有該鎖，若已經(jīng)擁有，直接對(duì)鎖的重入次數(shù)加 1。

若還沒擁有該鎖，則嘗試去 Redis 加鎖，加鎖成功之后，再對(duì)重入次數(shù)加 1 。

釋放鎖的代碼如下：

  
 
 
 

   
  
  
  
/**
   
  
  
  
 * 解鎖需要判斷不同線程池
   
  
  
  
 *
   
  
  
  
 * @param lockName
   
  
  
  
 * @param request
   
  
  
  
 */
   
  
  
  
public void unlock(String lockName, String request) {
   
  
  
  
    Map counts = LOCKS.get();
   
  
  
  
    if (counts.getOrDefault(lockName, 0) <= 1) {
   
  
  
  
        counts.remove(lockName);
   
  
  
  
        Boolean result = redisLock.unlock(lockName, request);
   
  
  
  
        if (!result) {
   
  
  
  
            throw new IllegalMonitorStateException("attempt to unlock lock, not locked by lockName:+" + lockName + " with request: "
   
  
  
  
                    + request);
   
  
  
  
        }
   
  
  
  

   
  
  
  
    } else {
   
  
  
  
        counts.put(lockName, counts.get(lockName) - 1);
   
  
  
  
    }
   
  
  
  
}
  
 
 
 

釋放鎖的時(shí)首先判斷重入次數(shù)，若大于 1，則代表該鎖是被該線程擁有，所以直接將鎖重入次數(shù)減 1 即可。

若當(dāng)前可重入次數(shù)小于等于 1，首先移除 Map中鎖對(duì)應(yīng)的 key，然后再到 Redis 釋放鎖。

這里需要注意的是，當(dāng)鎖未被該線程擁有，直接解鎖，可重入次數(shù)也是小于等于 1 ，這次可能無法直接解鎖成功。

“ThreadLocal 使用過程要記得及時(shí)清理內(nèi)部存儲(chǔ)實(shí)例變量，防止發(fā)生內(nèi)存泄漏，上下文數(shù)據(jù)串用等問題。下次咱來聊聊最近使用 ThreadLocal 寫的 Bug。

相關(guān)問題

使用 ThreadLocal 這種本地記錄重入次數(shù)，雖然真的簡(jiǎn)單高效，但是也存在一些問題。

過期時(shí)間問題

上述加鎖的代碼可以看到，重入加鎖時(shí)，僅僅對(duì)本地計(jì)數(shù)加 1 而已。這樣可能就會(huì)導(dǎo)致一種情況，由于業(yè)務(wù)執(zhí)行過長(zhǎng)，Redis 已經(jīng)過期釋放鎖。

而再次重入加鎖時(shí)，由于本地還存在數(shù)據(jù)，認(rèn)為鎖還在被持有，這就不符合實(shí)際情況。

如果要在本地增加過期時(shí)間，還需要考慮本地與 Redis 過期時(shí)間一致性的，代碼就會(huì)變得很復(fù)雜。

不同線程/進(jìn)程可重入問題

狹義上可重入性應(yīng)該只是對(duì)于同一線程的可重入，但是實(shí)際業(yè)務(wù)可能需要不同的應(yīng)用線程之間可以重入同把鎖。

而 ThreadLocal的方案僅僅只能滿足同一線程重入，無法解決不同線程/進(jìn)程之間重入問題。

不同線程/進(jìn)程重入問題就需要使用下述方案 Redis Hash 方案解決。

基于 Redis Hash 可重入鎖

實(shí)現(xiàn)方式

ThreadLocal 的方案中我們使用了 Map 記載鎖的可重入次數(shù)，而 Redis 也同樣提供了 Hash (哈希表)這種可以存儲(chǔ)鍵值對(duì)數(shù)據(jù)結(jié)構(gòu)。所以我們可以使用 Redis Hash 存儲(chǔ)的鎖的重入次數(shù)，然后利用 lua 腳本判斷邏輯。

加鎖的 lua 腳本如下：

  
 
 
 

   
  
  
  
---- 1 代表 true
   
  
  
  
---- 0 代表 false
   
  
  
  

   
  
  
  
if (redis.call('exists', KEYS[1]) == 0) then
   
  
  
  
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
   
  
  
  
    redis.call('pexpire', KEYS[1], ARGV[1]);
   
  
  
  
    return 1;
   
  
  
  
end ;
   
  
  
  
if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then
   
  
  
  
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
   
  
  
  
    redis.call('pexpire', KEYS[1], ARGV[1]);
   
  
  
  
    return 1;
   
  
  
  
end ;
   
  
  
  
return 0;
  
 
 
 

“如果 KEYS:[lock],ARGV[1000,uuid]

不熟悉 lua 語言同學(xué)也不要怕，上述邏輯還是比較簡(jiǎn)單的。

加鎖代碼首先使用 Redis exists 命令判斷當(dāng)前 lock 這個(gè)鎖是否存在。

如果鎖不存在的話，直接使用 hincrby創(chuàng)建一個(gè)鍵為 lock hash 表，并且為 Hash 表中鍵為 uuid 初始化為 0，然后再次加 1，最后再設(shè)置過期時(shí)間。

如果當(dāng)前鎖存在，則使用 hexists判斷當(dāng)前 lock 對(duì)應(yīng)的 hash 表中是否存在 uuid 這個(gè)鍵，如果存在,再次使用 hincrby 加 1，最后再次設(shè)置過期時(shí)間。

最后如果上述兩個(gè)邏輯都不符合，直接返回。

加鎖代碼如下:

  
 
 
 

   
  
  
  
// 初始化代碼
   
  
  
  

   
  
  
  
String lockLuaScript = IOUtils.toString(ResourceUtils.getURL("classpath:lock.lua").openStream(), Charsets.UTF_8);
   
  
  
  
lockScript = new DefaultRedisScript<>(lockLuaScript, Boolean.class);
   
  
  
  

   
  
  
  
/**
   
  
  
  
 * 可重入鎖
   
  
  
  
 *
   
  
  
  
 * @param lockName  鎖名字,代表需要爭(zhēng)臨界資源
   
  
  
  
 * @param request   唯一標(biāo)識(shí)，可以使用 uuid，根據(jù)該值判斷是否可以重入
   
  
  
  
 * @param leaseTime 鎖釋放時(shí)間
   
  
  
  
 * @param unit      鎖釋放時(shí)間單位
   
  
  
  
 * @return
   
  
  
  
 */
   
  
  
  
public Boolean tryLock(String lockName, String request, long leaseTime, TimeUnit unit) {
   
  
  
  
    long internalLockLeaseTime = unit.toMillis(leaseTime);
   
  
  
  
    return stringRedisTemplate.execute(lockScript, Lists.newArrayList(lockName), String.valueOf(internalLockLeaseTime), request);
   
  
  
  
}
  
 
 
 

“Spring-Boot 2.2.7.RELEASE

只要搞懂 Lua 腳本加鎖邏輯，Java 代碼實(shí)現(xiàn)還是挺簡(jiǎn)單的，直接使用 SpringBoot 提供的 StringRedisTemplate 即可。

解鎖的 Lua 腳本如下：

  
 
 
 

   
  
  
  
-- 判斷 hash set 可重入 key 的值是否等于 0
   
  
  
  
-- 如果為 0 代表 該可重入 key 不存在
   
  
  
  
if (redis.call('hexists', KEYS[1], ARGV[1]) == 0) then
   
  
  
  
    return nil;
   
  
  
  
end ;
   
  
  
  
-- 計(jì)算當(dāng)前可重入次數(shù)
   
  
  
  
local counter = redis.call('hincrby', KEYS[1], ARGV[1], -1);
   
  
  
  
-- 小于等于 0 代表可以解鎖
   
  
  
  
if (counter > 0) then
   
  
  
  
    return 0;
   
  
  
  
else
   
  
  
  
    redis.call('del', KEYS[1]);
   
  
  
  
    return 1;
   
  
  
  
end ;
   
  
  
  
return nil;
  
 
 
 

首先使用 hexists 判斷 Redis Hash 表是否存給定的域。

如果 lock 對(duì)應(yīng) Hash 表不存在，或者 Hash 表不存在 uuid 這個(gè) key，直接返回 nil。

若存在的情況下，代表當(dāng)前鎖被其持有，首先使用 hincrby使可重入次數(shù)減 1 ，然后判斷計(jì)算之后可重入次數(shù)，若小于等于 0，則使用 del 刪除這把鎖。

解鎖的 Java 代碼如下：

  
 
 
 

   
  
  
  
// 初始化代碼：
   
  
  
  

   
  
  
  

   
  
  
  
String unlockLuaScript = IOUtils.toString(ResourceUtils.getURL("classpath:unlock.lua").openStream(), Charsets.UTF_8);
   
  
  
  
unlockScript = new DefaultRedisScript<>(unlockLuaScript, Long.class);
   
  
  
  

   
  
  
  
/**
   
  
  
  
 * 解鎖
   
  
  
  
 * 若可重入 key 次數(shù)大于 1，將可重入 key 次數(shù)減 1 

   
  
  
  
 * 解鎖 lua 腳本返回含義：

   
  
  
  
 * 1:代表解鎖成功 

   
  
  
  
 * 0:代表鎖未釋放，可重入次數(shù)減 1 

   
  
  
  
 * nil：代表其他線程嘗試解鎖 

   
  
  
  
 * 

   
  
  
  
 * 如果使用 DefaultRedisScript，由于 Spring-data-redis eval 類型轉(zhuǎn)化，

   
  
  
  
 * 當(dāng) Redis 返回  Nil bulk, 默認(rèn)將會(huì)轉(zhuǎn)化為 false，將會(huì)影響解鎖語義，所以下述使用：

   
  
  
  
 * DefaultRedisScript
   
  
  
  
 * 

   
  
  
  
 * 具體轉(zhuǎn)化代碼請(qǐng)查看：

   
  
  
  
 * JedisScriptReturnConverter

   
  
  
  
 *
   
  
  
  
 * @param lockName 鎖名稱
   
  
  
  
 * @param request  唯一標(biāo)識(shí)，可以使用 uuid
   
  
  
  
 * @throws IllegalMonitorStateException 解鎖之前，請(qǐng)先加鎖。若為加鎖，解鎖將會(huì)拋出該錯(cuò)誤
   
  
  
  
 */
   
  
  
  
public void unlock(String lockName, String request) {
   
  
  
  
    Long result = stringRedisTemplate.execute(unlockScript, Lists.newArrayList(lockName), request);
   
  
  
  
    // 如果未返回值，代表其他線程嘗試解鎖
   
  
  
  
    if (result == null) {
   
  
  
  
        throw new IllegalMonitorStateException("attempt to unlock lock, not locked by lockName:+" + lockName + " with request: "
   
  
  
  
                + request);
   
  
  
  
    }
   
  
  
  
}
  
 
 
 

解鎖代碼執(zhí)行方式與加鎖類似，只不過解鎖的執(zhí)行結(jié)果返回類型使用 Long。這里之所以沒有跟加鎖一樣使用 Boolean ,這是因?yàn)榻怄i lua 腳本中，三個(gè)返回值含義如下：

• 1 代表解鎖成功，鎖被釋放
• 0 代表可重入次數(shù)被減 1
• null 代表其他線程嘗試解鎖，解鎖失敗

如果返回值使用 Boolean，Spring-data-redis 進(jìn)行類型轉(zhuǎn)換時(shí)將會(huì)把 null 轉(zhuǎn)為 false，這就會(huì)影響我們邏輯判斷，所以返回類型只好使用 Long。

以下代碼來自 JedisScriptReturnConverter：

相關(guān)問題

spring-data-redis 低版本問題

如果 Spring-Boot 使用 Jedis 作為連接客戶端,并且使用Redis Cluster 集群模式，需要使用 2.1.9 以上版本的spring-boot-starter-data-redis,不然執(zhí)行過程中將會(huì)拋出：

  
 
 
 

   
  
  
  
org.springframework.dao.InvalidDataAccessApiUsageException: EvalSha is not supported in cluster environment.
  
 
 
 

如果當(dāng)前應(yīng)用無法升級(jí) spring-data-redis也沒關(guān)系，可以使用如下方式，直接使用原生 Jedis 連接執(zhí)行 lua 腳本。

以加鎖代碼為例：

  
 
 
 

   
  
  
  
public boolean tryLock(String lockName, String reentrantKey, long leaseTime, TimeUnit unit) {
   
  
  
  
    long internalLockLeaseTime = unit.toMillis(leaseTime);
   
  
  
  
    Boolean result = stringRedisTemplate.execute((RedisCallback) connection -> {
   
  
  
  
        Object innerResult = eval(connection.getNativeConnection(), lockScript, Lists.newArrayList(lockName), Lists.newArrayList(String.valueOf(internalLockLeaseTime), reentrantKey));
   
  
  
  
        return convert(innerResult);
   
  
  
  
    });
   
  
  
  
    return result;
   
  
  
  
}
   
  
  
  

   
  
  
  
private Object eval(Object nativeConnection, RedisScript redisScript, final List keys, final List args) {
   
  
  
  

   
  
  
  
    Object innerResult = null;
   
  
  
  
    // 集群模式和單點(diǎn)模式雖然執(zhí)行腳本的方法一樣，但是沒有共同的接口，所以只能分開執(zhí)行
   
  
  
  
    // 集群
   
  
  
  
    if (nativeConnection instanceof JedisCluster) {
   
  
  
  
        innerResult = evalByCluster((JedisCluster) nativeConnection, redisScript, keys, args);
   
  
  
  
    }
   
  
  
  
    // 單點(diǎn)
   
  
  
  
    else if (nativeConnection instanceof Jedis) {
   
  
  
  
        innerResult = evalBySingle((Jedis) nativeConnection, redisScript, keys, args);
   
  
  
  
    }
   
  
  
  
    return innerResult;
   
  
  
  
}
  
 
 
 

數(shù)據(jù)類型轉(zhuǎn)化問題

如果使用 Jedis 原生連接執(zhí)行 Lua 腳本，那么可能又會(huì)碰到數(shù)據(jù)類型的轉(zhuǎn)換坑。

可以看到 Jedis#eval返回 Object，我們需要具體根據(jù) Lua 腳本的返回值的，再進(jìn)行相關(guān)轉(zhuǎn)化。這其中就涉及到 Lua 數(shù)據(jù)類型轉(zhuǎn)化為 Redis 數(shù)據(jù)類型。

下面主要我們來講下 Lua 數(shù)據(jù)轉(zhuǎn)化 Redis 的規(guī)則中幾條比較容易踩坑：

1、Lua number 與 Redis 數(shù)據(jù)類型轉(zhuǎn)換

Lua 中 number 類型是一個(gè)雙精度的浮點(diǎn)數(shù)，但是 Redis 只支持整數(shù)類型，所以這個(gè)轉(zhuǎn)化過程將會(huì)丟棄小數(shù)位。

2、Lua boolean 與 Redis 類型轉(zhuǎn)換

這個(gè)轉(zhuǎn)化比較容易踩坑，Redis 中是不存在 boolean 類型，所以當(dāng)Lua 中 true 將會(huì)轉(zhuǎn)為 Redis 整數(shù) 1。而 Lua 中 false 并不是轉(zhuǎn)化整數(shù)，而是轉(zhuǎn)化 null 返回給客戶端。

3、Lua nil 與 Redis 類型轉(zhuǎn)換

Lua nil 可以當(dāng)做是一個(gè)空值，可以等同于 Java 中的 null。在 Lua 中如果 nil 出現(xiàn)在條件表達(dá)式，將會(huì)當(dāng)做 false 處理。

所以 Lua nil 也將會(huì) null 返回給客戶端。

其他轉(zhuǎn)化規(guī)則比較簡(jiǎn)單，詳情參考:

http://doc.redisfans.com/script/eval.html

總結(jié)

可重入分布式鎖關(guān)鍵在于對(duì)于鎖重入的計(jì)數(shù)，這篇文章主要給出兩種解決方案，一種基于 ThreadLocal 實(shí)現(xiàn)方案，這種方案實(shí)現(xiàn)簡(jiǎn)單，運(yùn)行也比較高效。但是若要處理鎖過期的問題，代碼實(shí)現(xiàn)就比較復(fù)雜。

另外一種采用 Redis Hash 數(shù)據(jù)結(jié)構(gòu)實(shí)現(xiàn)方案，解決了 ThreadLocal 的缺陷，但是代碼實(shí)現(xiàn)難度稍大，需要熟悉 Lua 腳本，以及Redis 一些命令。另外使用 spring-data-redis 等操作 Redis 時(shí)不經(jīng)意間就會(huì)遇到各種問題。

幫助

https://www.sofastack.tech/blog/sofa-jraft-rheakv-distributedlock/

https://tech.meituan.com/2016/09/29/distributed-system-mutually-exclusive-idempotence-cerberus-gtis.html

網(wǎng)站題目：老大吩咐的可重入分布式鎖，終于實(shí)現(xiàn)了~
轉(zhuǎn)載來源：http://www.5511xx.com/article/dpjigcc.html