# 產(chǎn)生背景
Distributed locks are a very useful primitive in many environments where different processes must operate with shared resources in a mutually exclusive way.
在某些場(chǎng)景中，多個(gè)進(jìn)程必須以互斥的方式獨(dú)占共享資源，這時(shí)用分布式鎖是最直接有效的。
隨著互聯(lián)網(wǎng)技術(shù)快速發(fā)展，數(shù)據(jù)規(guī)模增大，分布式系統(tǒng)越來(lái)越普及，一個(gè)應(yīng)用往往會(huì)部署在多臺(tái)機(jī)器上（多節(jié)點(diǎn)），在有些場(chǎng)景中，為了保證數(shù)據(jù)不重復(fù)，要求在同一時(shí)刻，同一任務(wù)只在一個(gè)節(jié)點(diǎn)上運(yùn)行，即保證某一方法同一時(shí)刻只能被一個(gè)線程執(zhí)行。在單機(jī)環(huán)境中，應(yīng)用是在同一進(jìn)程下的，只需要保證單進(jìn)程多線程環(huán)境中的線程安全性，通過 JAVA 提供的 volatile、ReentrantLock、synchronized 以及 concurrent 并發(fā)包下一些線程安全的類等就可以做到。而在多機(jī)部署環(huán)境中，不同機(jī)器不同進(jìn)程，就需要在多進(jìn)程下保證線程的安全性了。因此，分布式鎖應(yīng)運(yùn)而生。
# 實(shí)現(xiàn)分布式鎖的三種選擇
- 基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖
- 基于zookeeper實(shí)現(xiàn)分布式鎖
- 基于Redis緩存實(shí)現(xiàn)分布式鎖
以上三種方式都可以實(shí)現(xiàn)分布式鎖，其中，從健壯性考慮， 用 zookeeper 會(huì)比用 Redis 實(shí)現(xiàn)更好，但從性能角度考慮，基于 Redis 實(shí)現(xiàn)性能會(huì)更好，如何選擇，還是取決于業(yè)務(wù)需求。
# 基于 Redis 實(shí)現(xiàn)分布式鎖的三種方案
- 用 Redis 實(shí)現(xiàn)分布式鎖的正確姿勢(shì)（實(shí)現(xiàn)一）
- 用 Redisson 實(shí)現(xiàn)分布式可重入鎖（RedissonLock）（實(shí)現(xiàn)二）
- 用 Redisson 實(shí)現(xiàn)分布式鎖(紅鎖 RedissonRedLock)（實(shí)現(xiàn)三）
本文主要探討基于 Redis 實(shí)現(xiàn)分布式鎖的方案，主要分析并對(duì)比了以上三種方案，并大致分析了 Redisson 的 RedissonLock 、 RedissonRedLock 源碼。
# 分布式鎖需滿足四個(gè)條件
首先，為了確保分布式鎖可用，我們至少要確保鎖的實(shí)現(xiàn)同時(shí)滿足以下四個(gè)條件：
- 互斥性。在任意時(shí)刻，只有一個(gè)客戶端能持有鎖。
- 不會(huì)發(fā)生死鎖。即使有一個(gè)客戶端在持有鎖的期間崩潰而沒有主動(dòng)解鎖，也能保證后續(xù)其他客戶端能加鎖。
- 解鈴還須系鈴人。加鎖和解鎖必須是同一個(gè)客戶端，客戶端自己不能把別人加的鎖給解了，即不能誤解鎖。
- 具有容錯(cuò)性。只要大多數(shù)Redis節(jié)點(diǎn)正常運(yùn)行，客戶端就能夠獲取和釋放鎖。
# 用 Redis 實(shí)現(xiàn)分布式鎖的正確姿勢(shì)（實(shí)現(xiàn)一）
主要思路
通過 set key value px milliseconds nx 命令實(shí)現(xiàn)加鎖， 通過Lua腳本實(shí)現(xiàn)解鎖。核心實(shí)現(xiàn)命令如下：
//獲取鎖（unique_value可以是UUID等）
SET resource_name unique_value NX PX 30000
//釋放鎖（lua腳本中，一定要比較value，防止誤解鎖）
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
這種實(shí)現(xiàn)方式主要有以下幾個(gè)要點(diǎn)：
set 命令要用 set key value px milliseconds nx，替代 setnx + expire 需要分兩次執(zhí)行命令的方式，保證了原子性，
value 要具有唯一性，可以使用UUID.randomUUID().toString()方法生成，用來(lái)標(biāo)識(shí)這把鎖是屬于哪個(gè)請(qǐng)求加的，在解鎖的時(shí)候就可以有依據(jù)；
釋放鎖時(shí)要驗(yàn)證 value 值，防止誤解鎖；
通過 Lua 腳本來(lái)避免 Check And Set 模型的并發(fā)問題，因?yàn)樵卺尫沛i的時(shí)候因?yàn)樯婕暗蕉鄠€(gè)Redis操作 （利用了eval命令執(zhí)行Lua腳本的原子性）；
完整代碼實(shí)現(xiàn)如下：
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";
private static final Long RELEASE_SUCCESS = 1L;
/**
* 獲取分布式鎖(加鎖代碼)
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請(qǐng)求標(biāo)識(shí)
* @param expireTime 超期時(shí)間
* @return 是否獲取成功
*/
public static boolean getDistributedLock(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;
}
/**
* 釋放分布式鎖(解鎖代碼)
* @param jedis Redis客戶端
* @param lockKey 鎖
* @param requestId 請(qǐng)求標(biāo)識(shí)
* @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), C ollections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
}
}
加鎖代碼分析
首先，set()加入了NX參數(shù)，可以保證如果已有key存在，則函數(shù)不會(huì)調(diào)用成功，也就是只有一個(gè)客戶端能持有鎖，滿足互斥性。其次，由于我們對(duì)鎖設(shè)置了過期時(shí)間，即使鎖的持有者后續(xù)發(fā)生崩潰而沒有解鎖，鎖也會(huì)因?yàn)榈搅诉^期時(shí)間而自動(dòng)解鎖（即key被刪除），不會(huì)發(fā)生死鎖。最后，因?yàn)槲覀儗alue賦值為requestId，用來(lái)標(biāo)識(shí)這把鎖是屬于哪個(gè)請(qǐng)求加的，那么在客戶端在解鎖的時(shí)候就可以進(jìn)行校驗(yàn)是否是同一個(gè)客戶端。
解鎖代碼分析
將Lua代碼傳到j(luò)edis.eval()方法里，并使參數(shù)KEYS[1]賦值為lockKey，ARGV[1]賦值為requestId。在執(zhí)行的時(shí)候，首先會(huì)獲取鎖對(duì)應(yīng)的value值，檢查是否與requestId相等，如果相等則解鎖（刪除key）。
這種方式仍存在單點(diǎn)風(fēng)險(xiǎn)
以上實(shí)現(xiàn)在 Redis 正常運(yùn)行情況下是沒問題的，但如果存儲(chǔ)鎖對(duì)應(yīng)key的那個(gè)節(jié)點(diǎn)掛了的話，就可能存在丟失鎖的風(fēng)險(xiǎn)，導(dǎo)致出現(xiàn)多個(gè)客戶端持有鎖的情況，這樣就不能實(shí)現(xiàn)資源的獨(dú)享了。
- 客戶端A從master獲取到鎖
- 在master將鎖同步到slave之前，master宕掉了（Redis的主從同步通常是異步的）。
- 主從切換，slave節(jié)點(diǎn)被晉級(jí)為master節(jié)點(diǎn)
- 客戶端B取得了同一個(gè)資源被客戶端A已經(jīng)獲取到的另外一個(gè)鎖。導(dǎo)致存在同一時(shí)刻存不止一個(gè)線程獲取到鎖的情況。
所以在這種實(shí)現(xiàn)之下，不論Redis的部署架構(gòu)是單機(jī)模式、主從模式、哨兵模式還是集群模式，都存在這種風(fēng)險(xiǎn)。因?yàn)镽edis的主從同步是異步的。 運(yùn)行的是，Redis 之父 antirez 提出了 redlock算法 可以解決這個(gè)問題。
# Redisson 實(shí)現(xiàn)分布式可重入鎖及源碼分析 （RedissonLock）（實(shí)現(xiàn)二）
什么是 Redisson
Redisson是一個(gè)在Redis的基礎(chǔ)上實(shí)現(xiàn)的Java駐內(nèi)存數(shù)據(jù)網(wǎng)格（In-Memory Data Grid）。它不僅提供了一系列的分布式的Java常用對(duì)象，還實(shí)現(xiàn)了可重入鎖（Reentrant Lock）、公平鎖（Fair Lock、聯(lián)鎖（MultiLock）、 紅鎖（RedLock）、 讀寫鎖（ReadWriteLock）等，還提供了許多分布式服務(wù)。Redisson提供了使用Redis的最簡(jiǎn)單和最便捷的方法。Redisson的宗旨是促進(jìn)使用者對(duì)Redis的關(guān)注分離（Separation of Concern），從而讓使用者能夠?qū)⒕Ω械胤旁谔幚順I(yè)務(wù)邏輯上。
Redisson 分布式重入鎖用法
Redisson 支持單點(diǎn)模式、主從模式、哨兵模式、集群模式，這里以單點(diǎn)模式為例：
// 1.構(gòu)造redisson實(shí)現(xiàn)分布式鎖必要的Config
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:5379").setPassword("123456").setDatabase(0);
// 2.構(gòu)造RedissonClient
RedissonClient redissonClient = Redisson.create(config);
// 3.獲取鎖對(duì)象實(shí)例（無(wú)法保證是按線程的順序獲取到）
RLock rLock = redissonClient.getLock(lockKey);
try {
/**
* 4.嘗試獲取鎖
* waitTimeout 嘗試獲取鎖的最大等待時(shí)間，超過這個(gè)值，則認(rèn)為獲取鎖失敗
* leaseTime 鎖的持有時(shí)間,超過這個(gè)時(shí)間鎖會(huì)自動(dòng)失效（值應(yīng)設(shè)置為大于業(yè)務(wù)處理的時(shí)間，確保在鎖有效期內(nèi)業(yè)務(wù)能處理完）
*/
boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
if (res) {
//成功獲得鎖，在這里處理業(yè)務(wù)
}
} catch (Exception e) {
throw new RuntimeException("aquire lock fail");
}finally{
//無(wú)論如何, 最后都要解鎖
rLock.unlock();
}
加鎖源碼分析
1.通過 getLock 方法獲取對(duì)象
org.redisson.Redisson#getLock()
@Override
public RLock getLock(String name) {
/**
* 構(gòu)造并返回一個(gè) RedissonLock 對(duì)象
* commandExecutor: 與 Redis 節(jié)點(diǎn)通信并發(fā)送指令的真正實(shí)現(xiàn)。需要說明一下，CommandExecutor 實(shí)現(xiàn)是通過 eval 命令來(lái)執(zhí)行 Lua 腳本
* name: 鎖的全局名稱
* id: Redisson 客戶端唯一標(biāo)識(shí)，實(shí)際上就是一個(gè) UUID.randomUUID()
*/
return new RedissonLock(commandExecutor, name, id);
}
2.通過tryLock方法嘗試獲取鎖
tryLock方法里的調(diào)用關(guān)系大致如下：
org.redisson.RedissonLock#tryLock
@Override
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
//取得最大等待時(shí)間
long time = unit.toMillis(waitTime);
//記錄下當(dāng)前時(shí)間
long current = System.currentTimeMillis();
//取得當(dāng)前線程id（判斷是否可重入鎖的關(guān)鍵）
long threadId = Thread.currentThread().getId();
//1.嘗試申請(qǐng)鎖，返回還剩余的鎖過期時(shí)間
Long ttl = tryAcquire(leaseTime, unit, threadId);
//2.如果為空，表示申請(qǐng)鎖成功
if (ttl == null) {
return true;
}
//3.申請(qǐng)鎖的耗時(shí)如果大于等于最大等待時(shí)間，則申請(qǐng)鎖失敗
time -= System.currentTimeMillis() - current;
if (time <= 0) {
/**
* 通過 promise.trySuccess 設(shè)置異步執(zhí)行的結(jié)果為null
* Promise從Uncompleted-->Completed ,通知 Future 異步執(zhí)行已完成
*/
acquireFailed(threadId);
return false;
}
current = System.currentTimeMillis();
/**
* 4.訂閱鎖釋放事件，并通過await方法阻塞等待鎖釋放，有效的解決了無(wú)效的鎖申請(qǐng)浪費(fèi)資源的問題：
* 基于信息量，當(dāng)鎖被其它資源占用時(shí)，當(dāng)前線程通過 Redis 的 channel 訂閱鎖的釋放事件，一旦鎖釋放會(huì)發(fā)消息通知待等待的線程進(jìn)行競(jìng)爭(zhēng)
* 當(dāng) this.await返回false，說明等待時(shí)間已經(jīng)超出獲取鎖最大等待時(shí)間，取消訂閱并返回獲取鎖失敗
* 當(dāng) this.await返回true，進(jìn)入循環(huán)嘗試獲取鎖
*/
RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
//await 方法內(nèi)部是用CountDownLatch來(lái)實(shí)現(xiàn)阻塞，獲取subscribe異步執(zhí)行的結(jié)果（應(yīng)用了Netty 的 Future）
if (!await(subscribeFuture, time, TimeUnit.MILLISECONDS)) {
if (!subscribeFuture.cancel(false)) {
subscribeFuture.onComplete((res, e) -> {
if (e == null) {
unsubscribe(subscribeFuture, threadId);
}
});
}
acquireFailed(threadId);
return false;
}
try {
//計(jì)算獲取鎖的總耗時(shí)，如果大于等于最大等待時(shí)間，則獲取鎖失敗
time -= System.currentTimeMillis() - current;
if (time <= 0) {
acquireFailed(threadId);
return false;
}
/**
* 5.收到鎖釋放的信號(hào)后，在最大等待時(shí)間之內(nèi)，循環(huán)一次接著一次的嘗試獲取鎖
* 獲取鎖成功，則立馬返回true，
* 若在最大等待時(shí)間之內(nèi)還沒獲取到鎖，則認(rèn)為獲取鎖失敗，返回false結(jié)束循環(huán)
*/
while (true) {
long currentTime = System.currentTimeMillis();
// 再次嘗試申請(qǐng)鎖
ttl = tryAcquire(leaseTime, unit, threadId);
// 成功獲取鎖則直接返回true結(jié)束循環(huán)
if (ttl == null) {
return true;
}
//超過最大等待時(shí)間則返回false結(jié)束循環(huán)，獲取鎖失敗
time -= System.currentTimeMillis() - currentTime;
if (time <= 0) {
acquireFailed(threadId);
return false;
}
/**
* 6.阻塞等待鎖（通過信號(hào)量(共享鎖)阻塞,等待解鎖消息）：
*/
currentTime = System.currentTimeMillis();
if (ttl >= 0 && ttl < time) {
//如果剩余時(shí)間(ttl)小于wait time ,就在 ttl 時(shí)間內(nèi)，從Entry的信號(hào)量獲取一個(gè)許可(除非被中斷或者一直沒有可用的許可)。
getEntry(threadId).getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
} else {
//則就在wait time 時(shí)間范圍內(nèi)等待可以通過信號(hào)量
getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
}
//7.更新剩余的等待時(shí)間(最大等待時(shí)間-已經(jīng)消耗的阻塞時(shí)間)
time -= System.currentTimeMillis() - currentTime;
if (time <= 0) {
acquireFailed(threadId);
return false;
}
}
} finally {
//7.無(wú)論是否獲得鎖,都要取消訂閱解鎖消息
unsubscribe(subscribeFuture, threadId);
}
}
其中 tryAcquire 內(nèi)部通過調(diào)用 tryLockInnerAsync 實(shí)現(xiàn)申請(qǐng)鎖的邏輯。申請(qǐng)鎖并返回鎖有效期還剩余的時(shí)間，如果為空說明鎖未被其它線程申請(qǐng)則直接獲取并返回，如果獲取到時(shí)間，則進(jìn)入等待競(jìng)爭(zhēng)邏輯。
org.redisson.RedissonLock#tryLockInnerAsync
加鎖流程圖：
實(shí)現(xiàn)源碼：
<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
internalLockLeaseTime = unit.toMillis(leaseTime);
/**
* 通過 EVAL 命令執(zhí)行 Lua 腳本獲取鎖，保證了原子性
*/
return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
// 1.如果緩存中的key不存在，則執(zhí)行 hset 命令(hset key UUID+threadId 1),然后通過 pexpire 命令設(shè)置鎖的過期時(shí)間(即鎖的租約時(shí)間)
// 返回空值 nil ，表示獲取鎖成功
"if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('hset', KEYS[1], ARGV[2], 1); " +
"redis.call('pexpire', KEYS[1], ARGV[1]); " +
"return nil; " +
"end; " +
// 如果key已經(jīng)存在，并且value也匹配，表示是當(dāng)前線程持有的鎖，則執(zhí)行 hincrby 命令，重入次數(shù)加1，并且設(shè)置失效時(shí)間
"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 nil; " +
"end; " +
//如果key已經(jīng)存在，但是value不匹配，說明鎖已經(jīng)被其他線程持有，通過 pttl 命令獲取鎖的剩余存活時(shí)間并返回，至此獲取鎖失敗
"return redis.call('pttl', KEYS[1]);",
//這三個(gè)參數(shù)分別對(duì)應(yīng)KEYS[1]，ARGV[1]和ARGV[2]
Collections.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
}
參數(shù)說明：
KEYS[1]就是Collections.singletonList(getName())，表示分布式鎖的key；
ARGV[1]就是internalLockLeaseTime，即鎖的租約時(shí)間（持有鎖的有效時(shí)間），默認(rèn)30s；
ARGV[2]就是getLockName(threadId)，是獲取鎖時(shí)set的唯一值 value，即UUID+threadId。
解鎖源碼分析
unlock 內(nèi)部通過 get(unlockAsync(Thread.currentThread().getId())) 調(diào)用 unlockInnerAsync 解鎖。
org.redisson.RedissonLock#unlock
@Override
public void unlock() {
try {
get(unlockAsync(Thread.currentThread().getId()));
} catch (RedisException e) {
if (e.getCause() instanceof IllegalMonitorStateException) {
throw (IllegalMonitorStateException) e.getCause();
} else {
throw e;
}
}
}
get方法利用是 CountDownLatch 在異步調(diào)用結(jié)果返回前將當(dāng)前線程阻塞，然后通過 Netty 的 FutureListener 在異步調(diào)用完成后解除阻塞，并返回調(diào)用結(jié)果。
org.redisson.command.CommandAsyncService#get
@Override
public <V> V get(RFuture<V> future) {
if (!future.isDone()) { //任務(wù)還沒完成
// 設(shè)置一個(gè)單線程的同步控制器
CountDownLatch l = new CountDownLatch(1);
future.onComplete((res, e) -> {
//操作完成時(shí)，喚醒在await()方法中等待的線程
l.countDown();
});
boolean interrupted = false;
while (!future.isDone()) {
try {
//阻塞等待
l.await();
} catch (InterruptedException e) {
interrupted = true;
break;
}
}
if (interrupted) {
Thread.currentThread().interrupt();
}
}
if (future.isSuccess()) {
return future.getNow();
}
throw convertException(future);
}
org.redisson.RedissonLock#unlockInnerAsync
解鎖流程圖：
實(shí)現(xiàn)源碼：
protected RFuture<Boolean> unlockInnerAsync(long threadId) {
/**
* 通過 EVAL 命令執(zhí)行 Lua 腳本獲取鎖，保證了原子性
*/
return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
//如果分布式鎖存在，但是value不匹配，表示鎖已經(jīng)被其他線程占用，無(wú)權(quán)釋放鎖，那么直接返回空值（解鈴還須系鈴人）
"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
"return nil;" +
"end; " +
//如果value匹配，則就是當(dāng)前線程占有分布式鎖，那么將重入次數(shù)減1
"local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
//重入次數(shù)減1后的值如果大于0，表示分布式鎖有重入過，那么只能更新失效時(shí)間，還不能刪除
"if (counter > 0) then " +
"redis.call('pexpire', KEYS[1], ARGV[2]); " +
"return 0; " +
"else " +
//重入次數(shù)減1后的值如果為0，這時(shí)就可以刪除這個(gè)KEY，并發(fā)布解鎖消息，返回1
"redis.call('del', KEYS[1]); " +
"redis.call('publish', KEYS[2], ARGV[1]); " +
"return 1; "+
"end; " +
"return nil;",
//這5個(gè)參數(shù)分別對(duì)應(yīng)KEYS[1]，KEYS[2]，ARGV[1]，ARGV[2]和ARGV[3]
Arrays.<Object>asList(getName(), getChannelName()), LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId));
}
解鎖消息處理
org.redisson.pubsub#onMessage
public class LockPubSub extends PublishSubscribe<RedissonLockEntry> {
public static final Long UNLOCK_MESSAGE = 0L;
public static final Long READ_UNLOCK_MESSAGE = 1L;
public LockPubSub(PublishSubscribeService service) {
super(service);
}
@Override
protected RedissonLockEntry createEntry(RPromise<RedissonLockEntry> newPromise) {
return new RedissonLockEntry(newPromise);
}
@Override
protected void onMessage(RedissonLockEntry value, Long message) {
/**
* 判斷是否是解鎖消息
*/
if (message.equals(UNLOCK_MESSAGE)) {
Runnable runnableToExecute = value.getListeners().poll();
if (runnableToExecute != null) {
runnableToExecute.run();
}
/**
* 釋放一個(gè)信號(hào)量，喚醒等待的entry.getLatch().tryAcquire去再次嘗試申請(qǐng)鎖
*/
value.getLatch().release();
} else if (message.equals(READ_UNLOCK_MESSAGE)) {
while (true) {
/**
* 如果還有其他Listeners回調(diào)，則也喚醒執(zhí)行
*/
Runnable runnableToExecute = value.getListeners().poll();
if (runnableToExecute == null) {
break;
}
runnableToExecute.run();
}
value.getLatch().release(value.getLatch().getQueueLength());
}
}
}
總結(jié)對(duì)比
通過 Redisson 實(shí)現(xiàn)分布式可重入鎖（實(shí)現(xiàn)二），比純自己通過set key value px milliseconds nx +lua 實(shí)現(xiàn)（實(shí)現(xiàn)一）的效果更好些，雖然基本原理都一樣，因?yàn)橥ㄟ^分析源碼可知，RedissonLock
是可重入的，并且考慮了失敗重試，可以設(shè)置鎖的最大等待時(shí)間， 在實(shí)現(xiàn)上也做了一些優(yōu)化，減少了無(wú)效的鎖申請(qǐng)，提升了資源的利用率。
需要特別注意的是，RedissonLock 同樣沒有解決 節(jié)點(diǎn)掛掉的時(shí)候，存在丟失鎖的風(fēng)險(xiǎn)的問題。而現(xiàn)實(shí)情況是有一些場(chǎng)景無(wú)法容忍的，所以 Redisson 提供了實(shí)現(xiàn)了redlock算法的 RedissonRedLock，RedissonRedLock 真正解決了單點(diǎn)失敗的問題，代價(jià)是需要額外的為 RedissonRedLock 搭建Redis環(huán)境。
所以，如果業(yè)務(wù)場(chǎng)景可以容忍這種小概率的錯(cuò)誤，則推薦使用 RedissonLock， 如果無(wú)法容忍，則推薦使用 RedissonRedLock。
# redlock算法
Redis 官網(wǎng)對(duì) redLock 算法的介紹大致如下：
在分布式版本的算法里我們假設(shè)我們有N個(gè)Redis master節(jié)點(diǎn)，這些節(jié)點(diǎn)都是完全獨(dú)立的，我們不用任何復(fù)制或者其他隱含的分布式協(xié)調(diào)機(jī)制。之前我們已經(jīng)描述了在Redis單實(shí)例下怎么安全地獲取和釋放鎖。我們確保將在每（N)個(gè)實(shí)例上使用此方法獲取和釋放鎖。在我們的例子里面我們把N設(shè)成5，這是一個(gè)比較合理的設(shè)置，所以我們需要在5臺(tái)機(jī)器上面或者5臺(tái)虛擬機(jī)上面運(yùn)行這些實(shí)例，這樣保證他們不會(huì)同時(shí)都宕掉。為了取到鎖，客戶端應(yīng)該執(zhí)行以下操作:
獲取當(dāng)前Unix時(shí)間，以毫秒為單位。
依次嘗試從5個(gè)實(shí)例，使用相同的key和具有唯一性的value（例如UUID）獲取鎖。當(dāng)向Redis請(qǐng)求獲取鎖時(shí)，客戶端應(yīng)該設(shè)置一個(gè)嘗試從某個(gè)Reids實(shí)例獲取鎖的最大等待時(shí)間（超過這個(gè)時(shí)間，則立馬詢問下一個(gè)實(shí)例），這個(gè)超時(shí)時(shí)間應(yīng)該小于鎖的失效時(shí)間。例如你的鎖自動(dòng)失效時(shí)間為10秒，則超時(shí)時(shí)間應(yīng)該在5-50毫秒之間。這樣可以避免服務(wù)器端Redis已經(jīng)掛掉的情況下，客戶端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒有在規(guī)定時(shí)間內(nèi)響應(yīng)，客戶端應(yīng)該盡快嘗試去另外一個(gè)Redis實(shí)例請(qǐng)求獲取鎖。
客戶端使用當(dāng)前時(shí)間減去開始獲取鎖時(shí)間（步驟1記錄的時(shí)間）就得到獲取鎖消耗的時(shí)間。當(dāng)且僅當(dāng)從大多數(shù)（N/2+1，這里是3個(gè)節(jié)點(diǎn)）的Redis節(jié)點(diǎn)都取到鎖，并且使用的總耗時(shí)小于鎖失效時(shí)間時(shí)，鎖才算獲取成功。
如果取到了鎖，key的真正有效時(shí)間 = 有效時(shí)間（獲取鎖時(shí)設(shè)置的key的自動(dòng)超時(shí)時(shí)間） - 獲取鎖的總耗時(shí)（詢問各個(gè)Redis實(shí)例的總耗時(shí)之和）（步驟3計(jì)算的結(jié)果）。
如果因?yàn)槟承┰颍罱K獲取鎖失敗（即沒有在至少 “N/2+1 ”個(gè)Redis實(shí)例取到鎖或者“獲取鎖的總耗時(shí)”超過了“有效時(shí)間”），客戶端應(yīng)該在所有的Redis實(shí)例上進(jìn)行解鎖（即便某些Redis實(shí)例根本就沒有加鎖成功，這樣可以防止某些節(jié)點(diǎn)獲取到鎖但是客戶端沒有得到響應(yīng)而導(dǎo)致接下來(lái)的一段時(shí)間不能被重新獲取鎖）。
# 用 Redisson 實(shí)現(xiàn)分布式鎖(紅鎖 RedissonRedLock)及源碼分析（實(shí)現(xiàn)三）
這里以三個(gè)單機(jī)模式為例，需要特別注意的是他們完全互相獨(dú)立，不存在主從復(fù)制或者其他集群協(xié)調(diào)機(jī)制。
Config config1 = new Config();
config1.useSingleServer().setAddress("redis://172.0.0.1:5378").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient1 = Redisson.create(config1);
Config config2 = new Config();
config2.useSingleServer().setAddress("redis://172.0.0.1:5379").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient2 = Redisson.create(config2);
Config config3 = new Config();
config3.useSingleServer().setAddress("redis://172.0.0.1:5380").setPassword("a123456").setDatabase(0);
RedissonClient redissonClient3 = Redisson.create(config3);
/**
* 獲取多個(gè) RLock 對(duì)象
*/
RLock lock1 = redissonClient1.getLock(lockKey);
RLock lock2 = redissonClient2.getLock(lockKey);
RLock lock3 = redissonClient3.getLock(lockKey);
/**
* 根據(jù)多個(gè) RLock 對(duì)象構(gòu)建 RedissonRedLock （最核心的差別就在這里）
*/
RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);
try {
/**
* 4.嘗試獲取鎖
* waitTimeout 嘗試獲取鎖的最大等待時(shí)間，超過這個(gè)值，則認(rèn)為獲取鎖失敗
* leaseTime 鎖的持有時(shí)間,超過這個(gè)時(shí)間鎖會(huì)自動(dòng)失效（值應(yīng)設(shè)置為大于業(yè)務(wù)處理的時(shí)間，確保在鎖有效期內(nèi)業(yè)務(wù)能處理完）
*/
boolean res = redLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
if (res) {
//成功獲得鎖，在這里處理業(yè)務(wù)
}
} catch (Exception e) {
throw new RuntimeException("aquire lock fail");
}finally{
//無(wú)論如何, 最后都要解鎖
redLock.unlock();
}
最核心的變化就是需要構(gòu)建多個(gè) RLock ,然后根據(jù)多個(gè) RLock 構(gòu)建成一個(gè) RedissonRedLock，因?yàn)?redLock 算法是建立在多個(gè)互相獨(dú)立的 Redis 環(huán)境之上的（為了區(qū)分可以叫為 Redission node），Redission node 節(jié)點(diǎn)既可以是單機(jī)模式(single)，也可以是主從模式(master/salve)，哨兵模式(sentinal)，或者集群模式(cluster)。這就意味著，不能跟以往這樣只搭建 1個(gè) cluster、或 1個(gè) sentinel 集群，或是1套主從架構(gòu)就了事了，需要為 RedissonRedLock 額外搭建多幾套獨(dú)立的 Redission 節(jié)點(diǎn)。 比如可以搭建3個(gè) 或者5個(gè) Redission節(jié)點(diǎn)，具體可看視資源及業(yè)務(wù)情況而定。
下圖是一個(gè)利用多個(gè) Redission node 最終 組成 RedLock分布式鎖的例子，需要特別注意的是每個(gè) Redission node 是互相獨(dú)立的，不存在任何復(fù)制或者其他隱含的分布式協(xié)調(diào)機(jī)制。
# Redisson 實(shí)現(xiàn)redlock算法源碼分析（RedLock）
加鎖核心代碼
org.redisson.RedissonMultiLock#tryLock
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
long newLeaseTime = -1;
if (leaseTime != -1) {
newLeaseTime = unit.toMillis(waitTime)*2;
}
long time = System.currentTimeMillis();
long remainTime = -1;
if (waitTime != -1) {
remainTime = unit.toMillis(waitTime);
}
long lockWaitTime = calcLockWaitTime(remainTime);
/**
* 1. 允許加鎖失敗節(jié)點(diǎn)個(gè)數(shù)限制（N-(N/2+1)）
*/
int failedLocksLimit = failedLocksLimit();
/**
* 2. 遍歷所有節(jié)點(diǎn)通過EVAL命令執(zhí)行l(wèi)ua加鎖
*/
List<RLock> acquiredLocks = new ArrayList<>(locks.size());
for (ListIterator<RLock> iterator = locks.listIterator(); iterator.hasNext();) {
RLock lock = iterator.next();
boolean lockAcquired;
/**
* 3.對(duì)節(jié)點(diǎn)嘗試加鎖
*/
try {
if (waitTime == -1 && leaseTime == -1) {
lockAcquired = lock.tryLock();
} else {
long awaitTime = Math.min(lockWaitTime, remainTime);
lockAcquired = lock.tryLock(awaitTime, newLeaseTime, TimeUnit.MILLISECONDS);
}
} catch (RedisResponseTimeoutException e) {
// 如果拋出這類異常，為了防止加鎖成功，但是響應(yīng)失敗，需要解鎖所有節(jié)點(diǎn)
unlockInner(Arrays.asList(lock));
lockAcquired = false;
} catch (Exception e) {
// 拋出異常表示獲取鎖失敗
lockAcquired = false;
}
if (lockAcquired) {
/**
*4. 如果獲取到鎖則添加到已獲取鎖集合中
*/
acquiredLocks.add(lock);
} else {
/**
* 5. 計(jì)算已經(jīng)申請(qǐng)鎖失敗的節(jié)點(diǎn)是否已經(jīng)到達(dá) 允許加鎖失敗節(jié)點(diǎn)個(gè)數(shù)限制 （N-(N/2+1)）
* 如果已經(jīng)到達(dá)， 就認(rèn)定最終申請(qǐng)鎖失敗，則沒有必要繼續(xù)從后面的節(jié)點(diǎn)申請(qǐng)了
* 因?yàn)?Redlock 算法要求至少N/2+1 個(gè)節(jié)點(diǎn)都加鎖成功，才算最終的鎖申請(qǐng)成功
*/
if (locks.size() - acquiredLocks.size() == failedLocksLimit()) {
break;
}
if (failedLocksLimit == 0) {
unlockInner(acquiredLocks);
if (waitTime == -1 && leaseTime == -1) {
return false;
}
failedLocksLimit = failedLocksLimit();
acquiredLocks.clear();
// reset iterator
while (iterator.hasPrevious()) {
iterator.previous();
}
} else {
failedLocksLimit--;
}
}
/**
* 6.計(jì)算 目前從各個(gè)節(jié)點(diǎn)獲取鎖已經(jīng)消耗的總時(shí)間，如果已經(jīng)等于最大等待時(shí)間，則認(rèn)定最終申請(qǐng)鎖失敗，返回false
*/
if (remainTime != -1) {
remainTime -= System.currentTimeMillis() - time;
time = System.currentTimeMillis();
if (remainTime <= 0) {
unlockInner(acquiredLocks);
return false;
}
}
}
if (leaseTime != -1) {
List<RFuture<Boolean>> futures = new ArrayList<>(acquiredLocks.size());
for (RLock rLock : acquiredLocks) {
RFuture<Boolean> future = ((RedissonLock) rLock).expireAsync(unit.toMillis(leaseTime), TimeUnit.MILLISECONDS);
futures.add(future);
}
for (RFuture<Boolean> rFuture : futures) {
rFuture.syncUninterruptibly();
}
}
/**
* 7.如果邏輯正常執(zhí)行完則認(rèn)為最終申請(qǐng)鎖成功，返回true
*/
return true;
}
# 參考文獻(xiàn)
[1]Distributed locks with Redis
[2]Distributed locks with Redis 中文版
[3]SET - Redis
[4]EVAL command
[5] Redisson
[6]Redis分布式鎖的正確實(shí)現(xiàn)方式
[8]Redisson實(shí)現(xiàn)Redis分布式鎖
此文首發(fā)于我的個(gè)人博客：
https://crazyfzw.github.io/2019/04/15/distributed-locks-with-redis/
