分布式鎖用 Redis 還是 Zookeeper?
在討論這個(gè)問(wèn)題之前,我們先來(lái)看一個(gè)業(yè)務(wù)場(chǎng)景:
系統(tǒng)A是一個(gè)電商系統(tǒng),目前是一臺(tái)機(jī)器部署,系統(tǒng)中有一個(gè)用戶下訂單的接口,但是用戶下訂單之前一定要去檢查一下庫(kù)存,確保庫(kù)存足夠了才會(huì)給用戶下單。
由于系統(tǒng)有一定的并發(fā),所以會(huì)預(yù)先將商品的庫(kù)存保存在redis中,用戶下單的時(shí)候會(huì)更新redis的庫(kù)存。
此時(shí)系統(tǒng)架構(gòu)如下:

但是這樣一來(lái)會(huì)產(chǎn)生一個(gè)問(wèn)題:假如某個(gè)時(shí)刻,redis里面的某個(gè)商品庫(kù)存為1,此時(shí)兩個(gè)請(qǐng)求同時(shí)到來(lái),其中一個(gè)請(qǐng)求執(zhí)行到上圖的第3步,更新數(shù)據(jù)庫(kù)的庫(kù)存為0,但是第4步還沒(méi)有執(zhí)行。
而另外一個(gè)請(qǐng)求執(zhí)行到了第2步,發(fā)現(xiàn)庫(kù)存還是1,就繼續(xù)執(zhí)行第3步。
這樣的結(jié)果,是導(dǎo)致賣出了2個(gè)商品,然而其實(shí)庫(kù)存只有1個(gè)。
很明顯不對(duì)啊!這就是典型的庫(kù)存超賣問(wèn)題
此時(shí),我們很容易想到解決方案:用鎖把2、3、4步鎖住,讓他們執(zhí)行完之后,另一個(gè)線程才能進(jìn)來(lái)執(zhí)行第2步。

按照上面的圖,在執(zhí)行第2步時(shí),使用Java提供的synchronized或者ReentrantLock來(lái)鎖住,然后在第4步執(zhí)行完之后才釋放鎖。
這樣一來(lái),2、3、4 這3個(gè)步驟就被“鎖”住了,多個(gè)線程之間只能串行化執(zhí)行。
但是好景不長(zhǎng),整個(gè)系統(tǒng)的并發(fā)飆升,一臺(tái)機(jī)器扛不住了。現(xiàn)在要增加一臺(tái)機(jī)器,如下圖:

增加機(jī)器之后,系統(tǒng)變成上圖所示,我的天!
假設(shè)此時(shí)兩個(gè)用戶的請(qǐng)求同時(shí)到來(lái),但是落在了不同的機(jī)器上,那么這兩個(gè)請(qǐng)求是可以同時(shí)執(zhí)行了,還是會(huì)出現(xiàn)庫(kù)存超賣的問(wèn)題。
為什么呢?因?yàn)樯蠄D中的兩個(gè)A系統(tǒng),運(yùn)行在兩個(gè)不同的JVM里面,他們加的鎖只對(duì)屬于自己JVM里面的線程有效,對(duì)于其他JVM的線程是無(wú)效的。
因此,這里的問(wèn)題是:Java提供的原生鎖機(jī)制在多機(jī)部署場(chǎng)景下失效了
這是因?yàn)閮膳_(tái)機(jī)器加的鎖不是同一個(gè)鎖(兩個(gè)鎖在不同的JVM里面)。
那么,我們只要保證兩臺(tái)機(jī)器加的鎖是同一個(gè)鎖,問(wèn)題不就解決了嗎?
此時(shí),就該分布式鎖隆重登場(chǎng)了,分布式鎖的思路是:
在整個(gè)系統(tǒng)提供一個(gè)全局、唯一的獲取鎖的“東西”,然后每個(gè)系統(tǒng)在需要加鎖時(shí),都去問(wèn)這個(gè)“東西”拿到一把鎖,這樣不同的系統(tǒng)拿到的就可以認(rèn)為是同一把鎖。
至于這個(gè)“東西”,可以是Redis、Zookeeper,也可以是數(shù)據(jù)庫(kù)。
文字描述不太直觀,我們來(lái)看下圖:

通過(guò)上面的分析,我們知道了庫(kù)存超賣場(chǎng)景在分布式部署系統(tǒng)的情況下使用Java原生的鎖機(jī)制無(wú)法保證線程安全,所以我們需要用到分布式鎖的方案。
那么,如何實(shí)現(xiàn)分布式鎖呢?接著往下看!
基于Redis實(shí)現(xiàn)分布式鎖
上面分析為啥要使用分布式鎖了,這里我們來(lái)具體看看分布式鎖落地的時(shí)候應(yīng)該怎么樣處理。擴(kuò)展:Redisson是如何實(shí)現(xiàn)分布式鎖的?
最常見的一種方案就是使用Redis做分布式鎖
使用Redis做分布式鎖的思路大概是這樣的:在redis中設(shè)置一個(gè)值表示加了鎖,然后釋放鎖的時(shí)候就把這個(gè)key刪除。
具體代碼是這樣的:
//?獲取鎖
//?NX是指如果key不存在就成功,key存在返回false,PX可以指定過(guò)期時(shí)間
SET?anyLock?unique_value?NX?PX?30000
//?釋放鎖:通過(guò)執(zhí)行一段lua腳本
//?釋放鎖涉及到兩條指令,這兩條指令不是原子性的
//?需要用到redis的lua腳本支持特性,redis執(zhí)行l(wèi)ua腳本是原子性的
if?redis.call("get",KEYS[1])?==?ARGV[1]?then
return?redis.call("del",KEYS[1])
else
return?0
end
這種方式有幾大要點(diǎn):
一定要用SET key value NX PX milliseconds 命令
如果不用,先設(shè)置了值,再設(shè)置過(guò)期時(shí)間,這個(gè)不是原子性操作,有可能在設(shè)置過(guò)期時(shí)間之前宕機(jī),會(huì)造成死鎖(key永久存在)
value要具有唯一性
這個(gè)是為了在解鎖的時(shí)候,需要驗(yàn)證value是和加鎖的一致才刪除key。
這是避免了一種情況:假設(shè)A獲取了鎖,過(guò)期時(shí)間30s,此時(shí)35s之后,鎖已經(jīng)自動(dòng)釋放了,A去釋放鎖,但是此時(shí)可能B獲取了鎖。A客戶端就不能刪除B的鎖了。

除了要考慮客戶端要怎么實(shí)現(xiàn)分布式鎖之外,還需要考慮redis的部署問(wèn)題。
redis有3種部署方式:
單機(jī)模式
master-slave + sentinel選舉模式
redis cluster模式
使用redis做分布式鎖的缺點(diǎn)在于:如果采用單機(jī)部署模式,會(huì)存在單點(diǎn)問(wèn)題,只要redis故障了。加鎖就不行了。
采用master-slave模式,加鎖的時(shí)候只對(duì)一個(gè)節(jié)點(diǎn)加鎖,即便通過(guò)sentinel做了高可用,但是如果master節(jié)點(diǎn)故障了,發(fā)生主從切換,此時(shí)就會(huì)有可能出現(xiàn)鎖丟失的問(wèn)題。
基于以上的考慮,其實(shí)redis的作者也考慮到這個(gè)問(wèn)題,他提出了一個(gè)RedLock的算法,這個(gè)算法的意思大概是這樣的:
假設(shè)redis的部署模式是redis cluster,總共有5個(gè)master節(jié)點(diǎn),通過(guò)以下步驟獲取一把鎖:
獲取當(dāng)前時(shí)間戳,單位是毫秒
輪流嘗試在每個(gè)master節(jié)點(diǎn)上創(chuàng)建鎖,過(guò)期時(shí)間設(shè)置較短,一般就幾十毫秒
嘗試在大多數(shù)節(jié)點(diǎn)上建立一個(gè)鎖,比如5個(gè)節(jié)點(diǎn)就要求是3個(gè)節(jié)點(diǎn)(n / 2 +1)
客戶端計(jì)算建立好鎖的時(shí)間,如果建立鎖的時(shí)間小于超時(shí)時(shí)間,就算建立成功了
要是鎖建立失敗了,那么就依次刪除這個(gè)鎖
只要?jiǎng)e人建立了一把分布式鎖,你就得不斷輪詢?nèi)L試獲取鎖
但是這樣的這種算法還是頗具爭(zhēng)議的,可能還會(huì)存在不少的問(wèn)題,無(wú)法保證加鎖的過(guò)程一定正確。

另一種方式:Redisson
此外,實(shí)現(xiàn)Redis的分布式鎖,除了自己基于redis client原生api來(lái)實(shí)現(xiàn)之外,還可以使用開源框架:Redission
Redisson是一個(gè)企業(yè)級(jí)的開源Redis Client,也提供了分布式鎖的支持。我也非常推薦大家使用,為什么呢?
回想一下上面說(shuō)的,如果自己寫代碼來(lái)通過(guò)redis設(shè)置一個(gè)值,是通過(guò)下面這個(gè)命令設(shè)置的。
SET anyLock unique_value NX PX 30000
這里設(shè)置的超時(shí)時(shí)間是30s,假如我超過(guò)30s都還沒(méi)有完成業(yè)務(wù)邏輯的情況下,key會(huì)過(guò)期,其他線程有可能會(huì)獲取到鎖。
這樣一來(lái)的話,第一個(gè)線程還沒(méi)執(zhí)行完業(yè)務(wù)邏輯,第二個(gè)線程進(jìn)來(lái)了也會(huì)出現(xiàn)線程安全問(wèn)題。所以我們還需要額外的去維護(hù)這個(gè)過(guò)期時(shí)間,太麻煩了~
我們來(lái)看看redisson是怎么實(shí)現(xiàn)的?先感受一下使用redission的爽:
Config?config?=?new?Config();
config.useClusterServers()
.addNodeAddress("redis://192.168.31.101:7001")
.addNodeAddress("redis://192.168.31.101:7002")
.addNodeAddress("redis://192.168.31.101:7003")
.addNodeAddress("redis://192.168.31.102:7001")
.addNodeAddress("redis://192.168.31.102:7002")
.addNodeAddress("redis://192.168.31.102:7003");
RedissonClient?redisson?=?Redisson.create(config);
RLock?lock?=?redisson.getLock("anyLock");
lock.lock();
lock.unlock();就是這么簡(jiǎn)單,我們只需要通過(guò)它的api中的lock和unlock即可完成分布式鎖,他幫我們考慮了很多細(xì)節(jié):
redisson所有指令都通過(guò)lua腳本執(zhí)行,redis支持lua腳本原子性執(zhí)行
redisson設(shè)置一個(gè)key的默認(rèn)過(guò)期時(shí)間為30s,如果某個(gè)客戶端持有一個(gè)鎖超過(guò)了30s怎么辦?
redisson中有一個(gè)
watchdog的概念,翻譯過(guò)來(lái)就是看門狗,它會(huì)在你獲取鎖之后,每隔10秒幫你把key的超時(shí)時(shí)間設(shè)為30s這樣的話,就算一直持有鎖也不會(huì)出現(xiàn)key過(guò)期了,其他線程獲取到鎖的問(wèn)題了。
redisson的“看門狗”邏輯保證了沒(méi)有死鎖發(fā)生。
(如果機(jī)器宕機(jī)了,看門狗也就沒(méi)了。此時(shí)就不會(huì)延長(zhǎng)key的過(guò)期時(shí)間,到了30s之后就會(huì)自動(dòng)過(guò)期了,其他線程可以獲取到鎖)

這里稍微貼出來(lái)其實(shí)現(xiàn)代碼:
//?加鎖邏輯
private??RFuture?tryAcquireAsync(long?leaseTime,?TimeUnit?unit,?final?long?threadId)? {
????if?(leaseTime?!=?-1)?{
????????return?tryLockInnerAsync(leaseTime,?unit,?threadId,?RedisCommands.EVAL_LONG);
????}
????//?調(diào)用一段lua腳本,設(shè)置一些key、過(guò)期時(shí)間
????RFuture?ttlRemainingFuture?=?tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(),?TimeUnit.MILLISECONDS,?threadId,?RedisCommands.EVAL_LONG);
????ttlRemainingFuture.addListener(new?FutureListener()?{
????????@Override
????????public?void?operationComplete(Future?future) ?throws?Exception?{
????????????if?(!future.isSuccess())?{
????????????????return;
????????????}
????????????Long?ttlRemaining?=?future.getNow();
????????????//?lock?acquired
????????????if?(ttlRemaining?==?null)?{
????????????????//?看門狗邏輯
????????????????scheduleExpirationRenewal(threadId);
????????????}
????????}
????});
????return?ttlRemainingFuture;
}
?RFuture?tryLockInnerAsync(long?leaseTime,?TimeUnit?unit,?long?threadId,?RedisStrictCommand?command) ? {
????internalLockLeaseTime?=?unit.toMillis(leaseTime);
????return?commandExecutor.evalWriteAsync(getName(),?LongCodec.INSTANCE,?command,
??????????????"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;?"?+
??????????????"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;?"?+
??????????????"return?redis.call('pttl',?KEYS[1]);",
????????????????Collections. 另外,redisson還提供了對(duì)redlock算法的支持,
它的用法也很簡(jiǎn)單:
RedissonClient?redisson?=?Redisson.create(config);
RLock?lock1?=?redisson.getFairLock("lock1");
RLock?lock2?=?redisson.getFairLock("lock2");
RLock?lock3?=?redisson.getFairLock("lock3");
RedissonRedLock?multiLock?=?new?RedissonRedLock(lock1,?lock2,?lock3);
multiLock.lock();
multiLock.unlock();
小結(jié):
本節(jié)分析了使用redis作為分布式鎖的具體落地方案
以及其一些局限性
然后介紹了一個(gè)redis的客戶端框架redisson,
這也是我推薦大家使用的,
比自己寫代碼實(shí)現(xiàn)會(huì)少care很多細(xì)節(jié)。
基于zookeeper實(shí)現(xiàn)分布式鎖
常見的分布式鎖實(shí)現(xiàn)方案里面,除了使用redis來(lái)實(shí)現(xiàn)之外,使用zookeeper也可以實(shí)現(xiàn)分布式鎖。
在介紹zookeeper(下文用zk代替)實(shí)現(xiàn)分布式鎖的機(jī)制之前,先粗略介紹一下zk是什么東西:
Zookeeper是一種提供配置管理、分布式協(xié)同以及命名的中心化服務(wù)。
zk的模型是這樣的:zk包含一系列的節(jié)點(diǎn),叫做znode,就好像文件系統(tǒng)一樣每個(gè)znode表示一個(gè)目錄,然后znode有一些特性:
有序節(jié)點(diǎn):假如當(dāng)前有一個(gè)父節(jié)點(diǎn)為
/lock,我們可以在這個(gè)父節(jié)點(diǎn)下面創(chuàng)建子節(jié)點(diǎn);zookeeper提供了一個(gè)可選的有序特性,例如我們可以創(chuàng)建子節(jié)點(diǎn)“/lock/node-”并且指明有序,那么zookeeper在生成子節(jié)點(diǎn)時(shí)會(huì)根據(jù)當(dāng)前的子節(jié)點(diǎn)數(shù)量自動(dòng)添加整數(shù)序號(hào)
也就是說(shuō),如果是第一個(gè)創(chuàng)建的子節(jié)點(diǎn),那么生成的子節(jié)點(diǎn)為
/lock/node-0000000000,下一個(gè)節(jié)點(diǎn)則為/lock/node-0000000001,依次類推。臨時(shí)節(jié)點(diǎn):客戶端可以建立一個(gè)臨時(shí)節(jié)點(diǎn),在會(huì)話結(jié)束或者會(huì)話超時(shí)后,zookeeper會(huì)自動(dòng)刪除該節(jié)點(diǎn)。
事件監(jiān)聽:在讀取數(shù)據(jù)時(shí),我們可以同時(shí)對(duì)節(jié)點(diǎn)設(shè)置事件監(jiān)聽,當(dāng)節(jié)點(diǎn)數(shù)據(jù)或結(jié)構(gòu)變化時(shí),zookeeper會(huì)通知客戶端。當(dāng)前zookeeper有如下四種事件:
節(jié)點(diǎn)創(chuàng)建
節(jié)點(diǎn)刪除
節(jié)點(diǎn)數(shù)據(jù)修改
子節(jié)點(diǎn)變更
基于以上的一些zk的特性,我們很容易得出使用zk實(shí)現(xiàn)分布式鎖的落地方案:
使用zk的臨時(shí)節(jié)點(diǎn)和有序節(jié)點(diǎn),每個(gè)線程獲取鎖就是在zk創(chuàng)建一個(gè)臨時(shí)有序的節(jié)點(diǎn),比如在/lock/目錄下。
創(chuàng)建節(jié)點(diǎn)成功后,獲取/lock目錄下的所有臨時(shí)節(jié)點(diǎn),再判斷當(dāng)前線程創(chuàng)建的節(jié)點(diǎn)是否是所有的節(jié)點(diǎn)的序號(hào)最小的節(jié)點(diǎn)
如果當(dāng)前線程創(chuàng)建的節(jié)點(diǎn)是所有節(jié)點(diǎn)序號(hào)最小的節(jié)點(diǎn),則認(rèn)為獲取鎖成功。
如果當(dāng)前線程創(chuàng)建的節(jié)點(diǎn)不是所有節(jié)點(diǎn)序號(hào)最小的節(jié)點(diǎn),則對(duì)節(jié)點(diǎn)序號(hào)的前一個(gè)節(jié)點(diǎn)添加一個(gè)事件監(jiān)聽。
比如當(dāng)前線程獲取到的節(jié)點(diǎn)序號(hào)為
/lock/003,然后所有的節(jié)點(diǎn)列表為[/lock/001,/lock/002,/lock/003],則對(duì)/lock/002這個(gè)節(jié)點(diǎn)添加一個(gè)事件監(jiān)聽器。
如果鎖釋放了,會(huì)喚醒下一個(gè)序號(hào)的節(jié)點(diǎn),然后重新執(zhí)行第3步,判斷是否自己的節(jié)點(diǎn)序號(hào)是最小。
比如/lock/001釋放了,/lock/002監(jiān)聽到時(shí)間,此時(shí)節(jié)點(diǎn)集合為[/lock/002,/lock/003],則/lock/002為最小序號(hào)節(jié)點(diǎn),獲取到鎖。
整個(gè)過(guò)程如下:

具體的實(shí)現(xiàn)思路就是這樣,至于代碼怎么寫,這里比較復(fù)雜就不貼出來(lái)了。
Curator介紹
Curator是一個(gè)zookeeper的開源客戶端,也提供了分布式鎖的實(shí)現(xiàn)。
他的使用方式也比較簡(jiǎn)單:
InterProcessMutex?interProcessMutex?=?new?InterProcessMutex(client,"/anyLock");
interProcessMutex.acquire();
interProcessMutex.release();其實(shí)現(xiàn)分布式鎖的核心源碼如下:
private?boolean?internalLockLoop(long?startMillis,?Long?millisToWait,?String?ourPath)?throws?Exception
{
????boolean??haveTheLock?=?false;
????boolean??doDelete?=?false;
????try?{
????????if?(?revocable.get()?!=?null?)?{
????????????client.getData().usingWatcher(revocableWatcher).forPath(ourPath);
????????}
????????while?(?(client.getState()?==?CuratorFrameworkState.STARTED)?&&?!haveTheLock?)?{
????????????//?獲取當(dāng)前所有節(jié)點(diǎn)排序后的集合
????????????List????????children?=?getSortedChildren();
????????????//?獲取當(dāng)前節(jié)點(diǎn)的名稱
????????????String??????????????sequenceNodeName?=?ourPath.substring(basePath.length()?+?1);?//?+1?to?include?the?slash
????????????//?判斷當(dāng)前節(jié)點(diǎn)是否是最小的節(jié)點(diǎn)
????????????PredicateResults????predicateResults?=?driver.getsTheLock(client,?children,?sequenceNodeName,?maxLeases);
????????????if?(?predicateResults.getsTheLock()?)?{
????????????????//?獲取到鎖
????????????????haveTheLock?=?true;
????????????}?else?{
????????????????//?沒(méi)獲取到鎖,對(duì)當(dāng)前節(jié)點(diǎn)的上一個(gè)節(jié)點(diǎn)注冊(cè)一個(gè)監(jiān)聽器
????????????????String??previousSequencePath?=?basePath?+?"/"?+?predicateResults.getPathToWatch();
????????????????synchronized(this){
????????????????????Stat?stat?=?client.checkExists().usingWatcher(watcher).forPath(previousSequencePath);
????????????????????if?(?stat?!=?null?){
????????????????????????if?(?millisToWait?!=?null?){
????????????????????????????millisToWait?-=?(System.currentTimeMillis()?-?startMillis);
????????????????????????????startMillis?=?System.currentTimeMillis();
????????????????????????????if?(?millisToWait?<=?0?){
????????????????????????????????doDelete?=?true;????//?timed?out?-?delete?our?node
????????????????????????????????break;
????????????????????????????}
????????????????????????????wait(millisToWait);
????????????????????????}else{
????????????????????????????wait();
????????????????????????}
????????????????????}
????????????????}
????????????????//?else?it?may?have?been?deleted?(i.e.?lock?released).?Try?to?acquire?again
????????????}
????????}
????}
????catch?(?Exception?e?)?{
????????doDelete?=?true;
????????throw?e;
????}?finally{
????????if?(?doDelete?){
????????????deleteOurPath(ourPath);
????????}
????}
????return?haveTheLock;
} 其實(shí)curator實(shí)現(xiàn)分布式鎖的底層原理和上面分析的是差不多的。這里我們用一張圖詳細(xì)描述其原理:

小結(jié):
本節(jié)介紹了zookeeperr實(shí)現(xiàn)分布式鎖的方案以及zk的開源客戶端的基本使用,簡(jiǎn)要的介紹了其實(shí)現(xiàn)原理。相關(guān)可以參考:肝一下ZooKeeper實(shí)現(xiàn)分布式鎖的方案,附帶實(shí)例!
兩種方案的優(yōu)缺點(diǎn)比較
學(xué)完了兩種分布式鎖的實(shí)現(xiàn)方案之后,本節(jié)需要討論的是redis和zk的實(shí)現(xiàn)方案中各自的優(yōu)缺點(diǎn)。
對(duì)于redis的分布式鎖而言,它有以下缺點(diǎn):
它獲取鎖的方式簡(jiǎn)單粗暴,獲取不到鎖直接不斷嘗試獲取鎖,比較消耗性能。
另外來(lái)說(shuō)的話,redis的設(shè)計(jì)定位決定了它的數(shù)據(jù)并不是強(qiáng)一致性的,在某些極端情況下,可能會(huì)出現(xiàn)問(wèn)題。鎖的模型不夠健壯
即便使用redlock算法來(lái)實(shí)現(xiàn),在某些復(fù)雜場(chǎng)景下,也無(wú)法保證其實(shí)現(xiàn)100%沒(méi)有問(wèn)題,關(guān)于redlock的討論可以看How to do distributed locking
redis分布式鎖,其實(shí)需要自己不斷去嘗試獲取鎖,比較消耗性能。
但是另一方面使用redis實(shí)現(xiàn)分布式鎖在很多企業(yè)中非常常見,而且大部分情況下都不會(huì)遇到所謂的“極端復(fù)雜場(chǎng)景”
所以使用redis作為分布式鎖也不失為一種好的方案,最重要的一點(diǎn)是redis的性能很高,可以支撐高并發(fā)的獲取、釋放鎖操作。
對(duì)于zk分布式鎖而言:
zookeeper天生設(shè)計(jì)定位就是分布式協(xié)調(diào),強(qiáng)一致性。鎖的模型健壯、簡(jiǎn)單易用、適合做分布式鎖。
如果獲取不到鎖,只需要添加一個(gè)監(jiān)聽器就可以了,不用一直輪詢,性能消耗較小。
但是zk也有其缺點(diǎn):如果有較多的客戶端頻繁的申請(qǐng)加鎖、釋放鎖,對(duì)于zk集群的壓力會(huì)比較大。
小結(jié):
綜上所述,redis和zookeeper都有其優(yōu)缺點(diǎn)。我們?cè)谧黾夹g(shù)選型的時(shí)候可以根據(jù)這些問(wèn)題作為參考因素。
建議
通過(guò)前面的分析,實(shí)現(xiàn)分布式鎖的兩種常見方案:redis和zookeeper,他們各有千秋。應(yīng)該如何選型呢?
就個(gè)人而言的話,我比較推崇zk實(shí)現(xiàn)的鎖:
因?yàn)閞edis是有可能存在隱患的,可能會(huì)導(dǎo)致數(shù)據(jù)不對(duì)的情況。但是,怎么選用要看具體在公司的場(chǎng)景了。
如果公司里面有zk集群條件,優(yōu)先選用zk實(shí)現(xiàn),但是如果說(shuō)公司里面只有redis集群,沒(méi)有條件搭建zk集群。
那么其實(shí)用redis來(lái)實(shí)現(xiàn)也可以,另外還可能是系統(tǒng)設(shè)計(jì)者考慮到了系統(tǒng)已經(jīng)有redis,但是又不希望再次引入一些外部依賴的情況下,可以選用redis。
這個(gè)是要系統(tǒng)設(shè)計(jì)者基于架構(gòu)的考慮了。

入骨相思知不知
玲瓏骰子安紅豆



入我相思門,知我相思苦,長(zhǎng)相思兮長(zhǎng)相憶,短相思兮無(wú)窮極。



