目錄
- 普通實現(xiàn)
- Redlock實現(xiàn)
- Redlock源碼
- 用法
- 唯一ID
- 獲取鎖
- 釋放鎖
普通實現(xiàn)
說道Redis分布式鎖大部分人都會想到：setnx+lua，或者知道set key value px milliseconds nx。后一種方式的核心實現(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
這種實現(xiàn)方式有3大要點（也是面試概率非常高的地方）：
- set命令要用set key value px milliseconds nx；
- value要具有唯一性；
- 釋放鎖時要驗證value值，不能誤解鎖；
事實上這類瑣最大的缺點就是它加鎖時只作用在一個Redis節(jié)點上，即使Redis通過sentinel保證高可用，如果這個master節(jié)點由于某些原因發(fā)生了主從切換，那么就會出現(xiàn)鎖丟失的情況：
- 在Redis的master節(jié)點上拿到了鎖；
- 但是這個加鎖的key還沒有同步到slave節(jié)點；
- master故障，發(fā)生故障轉(zhuǎn)移，slave節(jié)點升級為master節(jié)點；
- 導(dǎo)致鎖丟失。
正因為如此，Redis作者antirez基于分布式環(huán)境下提出了一種更高級的分布式鎖的實現(xiàn)方式：Redlock。筆者認(rèn)為，Redlock也是Redis所有分布式鎖實現(xiàn)方式中唯一能讓面試官高潮的方式。
Redlock實現(xiàn)
antirez提出的redlock算法大概是這樣的：
在Redis的分布式環(huán)境中，我們假設(shè)有N個Redis master。這些節(jié)點完全互相獨立，不存在主從復(fù)制或者其他集群協(xié)調(diào)機制。我們確保將在N個實例上使用與在Redis單實例下相同方法獲取和釋放鎖?，F(xiàn)在我們假設(shè)有5個Redis master節(jié)點，同時我們需要在5臺服務(wù)器上面運行這些Redis實例，這樣保證他們不會同時都宕掉。
為了取到鎖，客戶端應(yīng)該執(zhí)行以下操作:
- 獲取當(dāng)前Unix時間，以毫秒為單位。
- 依次嘗試從5個實例，使用相同的key和具有唯一性的value（例如UUID）獲取鎖。當(dāng)向Redis請求獲取鎖時，客戶端應(yīng)該設(shè)置一個網(wǎng)絡(luò)連接和響應(yīng)超時時間，這個超時時間應(yīng)該小于鎖的失效時間。例如你的鎖自動失效時間為10秒，則超時時間應(yīng)該在5-50毫秒之間。這樣可以避免服務(wù)器端Redis已經(jīng)掛掉的情況下，客戶端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒有在規(guī)定時間內(nèi)響應(yīng)，客戶端應(yīng)該盡快嘗試去另外一個Redis實例請求獲取鎖。
- 客戶端使用當(dāng)前時間減去開始獲取鎖時間（步驟1記錄的時間）就得到獲取鎖使用的時間。當(dāng)且僅當(dāng)從大多數(shù)（N/2+1，這里是3個節(jié)點）的Redis節(jié)點都取到鎖，并且使用的時間小于鎖失效時間時，鎖才算獲取成功。
- 如果取到了鎖，key的真正有效時間等于有效時間減去獲取鎖所使用的時間（步驟3計算的結(jié)果）。
- 如果因為某些原因，獲取鎖失?。]有在至少N/2+1個Redis實例取到鎖或者取鎖時間已經(jīng)超過了有效時間），客戶端應(yīng)該在所有的Redis實例上進(jìn)行解鎖（即便某些Redis實例根本就沒有加鎖成功，防止某些節(jié)點獲取到鎖但是客戶端沒有得到響應(yīng)而導(dǎo)致接下來的一段時間不能被重新獲取鎖）。
Redlock源碼
redisson已經(jīng)有對redlock算法封裝，接下來對其用法進(jìn)行簡單介紹，并對核心源碼進(jìn)行分析（假設(shè)5個redis實例）。
POM依賴
!-- https://mvnrepository.com/artifact/org.redisson/redisson -->
dependency>
groupId>org.redisson/groupId>
artifactId>redisson/artifactId>
version>3.3.2/version>
/dependency>
用法
首先，我們來看一下redission封裝的redlock算法實現(xiàn)的分布式鎖用法，非常簡單，跟重入鎖（ReentrantLock）有點類似：
Config config = new Config();
config.useSentinelServers().addSentinelAddress("127.0.0.1:6369","127.0.0.1:6379", "127.0.0.1:6389")
.setMasterName("masterName")
.setPassword("password").setDatabase(0);
RedissonClient redissonClient = Redisson.create(config);
// 還可以getFairLock(), getReadWriteLock()
RLock redLock = redissonClient.getLock("REDLOCK_KEY");
boolean isLock;
try {
isLock = redLock.tryLock();
// 500ms拿不到鎖, 就認(rèn)為獲取鎖失敗。10000ms即10s是鎖失效時間。
isLock = redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS);
if (isLock) {
//TODO if get lock success, do something;
}
} catch (Exception e) {
} finally {
// 無論如何, 最后都要解鎖
redLock.unlock();
}
唯一ID
實現(xiàn)分布式鎖的一個非常重要的點就是set的value要具有唯一性，redisson的value是怎樣保證value的唯一性呢？答案是UUID+threadId。入口在redissonClient.getLock("REDLOCK_KEY")，源碼在Redisson.java和RedissonLock.java中：
protected final UUID id = UUID.randomUUID();
String getLockName(long threadId) {
return id + ":" + threadId;
}
獲取鎖
獲取鎖的代碼為redLock.tryLock()或者redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS)，兩者的最終核心源碼都是下面這段代碼，只不過前者獲取鎖的默認(rèn)租約時間（leaseTime）是LOCK_EXPIRATION_INTERVAL_SECONDS，即30s：
T> RFutureT> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommandT> command) {
internalLockLeaseTime = unit.toMillis(leaseTime);
// 獲取鎖時向5個redis實例發(fā)送的命令
return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,
// 首先分布式鎖的KEY不能存在，如果確實不存在，那么執(zhí)行hset命令（hset REDLOCK_KEY uuid+threadId 1），并通過pexpire設(shè)置失效時間（也是鎖的租約時間）
"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)前線程持有的鎖，那么重入次數(shù)加1，并且設(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的失效時間毫秒數(shù)
"return redis.call('pttl', KEYS[1]);",
// 這三個參數(shù)分別對應(yīng)KEYS[1]，ARGV[1]和ARGV[2]
Collections.Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
}
獲取鎖的命令中，
- KEYS[1]就是Collections.singletonList(getName())，表示分布式鎖的key，即REDLOCK_KEY；
- ARGV[1]就是internalLockLeaseTime，即鎖的租約時間，默認(rèn)30s；
- ARGV[2]就是getLockName(threadId)，是獲取鎖時set的唯一值，即UUID+threadId：
釋放鎖
釋放鎖的代碼為redLock.unlock()，核心源碼如下：
protected RFutureBoolean> unlockInnerAsync(long threadId) {
// 向5個redis實例都執(zhí)行如下命令
return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, RedisCommands.EVAL_BOOLEAN,
// 如果分布式鎖KEY不存在，那么向channel發(fā)布一條消息
"if (redis.call('exists', KEYS[1]) == 0) then " +
"redis.call('publish', KEYS[2], ARGV[1]); " +
"return 1; " +
"end;" +
// 如果分布式鎖存在，但是value不匹配，表示鎖已經(jīng)被占用，那么直接返回
"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
"return nil;" +
"end; " +
// 如果就是當(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，表示分布式鎖只獲取過1次，那么刪除這個KEY，并發(fā)布解鎖消息
"redis.call('del', KEYS[1]); " +
"redis.call('publish', KEYS[2], ARGV[1]); " +
"return 1; "+
"end; " +
"return nil;",
// 這5個參數(shù)分別對應(yīng)KEYS[1]，KEYS[2]，ARGV[1]，ARGV[2]和ARGV[3]
Arrays.Object>asList(getName(), getChannelName()), LockPubSub.unlockMessage, internalLockLeaseTime, getLockName(threadId));
}
參考：https://redis.io/topics/distlock
到此這篇關(guān)于Redis分布式鎖Redlock的實現(xiàn)的文章就介紹到這了,更多相關(guān)Redis分布式鎖Redlock內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
您可能感興趣的文章:- Redis分布式限流組件設(shè)計與使用實例
- Java面試題沖刺第二十三天--分布式
- Redisson實現(xiàn)Redis分布式鎖的幾種方式
- Redis分布式非公平鎖的使用
- C#實現(xiàn)Redis的分布式鎖
- java基于mongodb實現(xiàn)分布式鎖的示例代碼
- 支持python的分布式計算框架Ray詳解
- LCN分布式事務(wù)解決方案詳解
