分布式鎖用Redis還是Zookeeper？
為什么用分布式鎖？
在討論這個(gè)問(wèn)題之前，我們先來(lái)看一個(gè)業(yè)務(wù)場(chǎng)景：
系統(tǒng)A是一個(gè)電商系統(tǒng)，目前是一臺(tái)機(jī)器部署，系統(tǒng)中有一個(gè)用戶(hù)下訂單的接口，但是用戶(hù)下訂單之前一定要去檢查一下庫(kù)存，確保庫(kù)存足夠了才會(huì)給用戶(hù)下單。
由于系統(tǒng)有一定的并發(fā)，所以會(huì)預(yù)先將商品的庫(kù)存保存在redis中，用戶(hù)下單的時(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)致賣(mài)出了2個(gè)商品，然而其實(shí)庫(kù)存只有1個(gè)。
很明顯不對(duì)啊！這就是典型的庫(kù)存超賣(mài)問(wèn)題
此時(shí)，我們很容易想到解決方案：用鎖把2、3、4步鎖住，讓他們執(zhí)行完之后，另一個(gè)線(xiàn)程才能進(jìn)來(lái)執(zhí)行第2步。
按照上面的圖，在執(zhí)行第2步時(shí)，使用Java提供的synchronized或者ReentrantLock來(lái)鎖住，然后在第4步執(zhí)行完之后才釋放鎖。
這樣一來(lái)，2、3、4 這3個(gè)步驟就被“鎖”住了，多個(gè)線(xiàn)程之間只能串行化執(zhí)行。
但是好景不長(zhǎng)，整個(gè)系統(tǒng)的并發(fā)飆升，一臺(tái)機(jī)器扛不住了?，F(xiàn)在要增加一臺(tái)機(jī)器，如下圖：
增加機(jī)器之后，系統(tǒng)變成上圖所示，我的天！
假設(shè)此時(shí)兩個(gè)用戶(hù)的請(qǐng)求同時(shí)到來(lái)，但是落在了不同的機(jī)器上，那么這兩個(gè)請(qǐng)求是可以同時(shí)執(zhí)行了，還是會(huì)出現(xiàn)庫(kù)存超賣(mài)的問(wèn)題。
為什么呢？因?yàn)樯蠄D中的兩個(gè)A系統(tǒng)，運(yùn)行在兩個(gè)不同的JVM里面，他們加的鎖只對(duì)屬于自己JVM里面的線(xiàn)程有效，對(duì)于其他JVM的線(xiàn)程是無(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ù)存超賣(mài)場(chǎng)景在分布式部署系統(tǒng)的情況下使用Java原生的鎖機(jī)制無(wú)法保證線(xiàn)程安全，所以我們需要用到分布式鎖的方案。
那么，如何實(shí)現(xiàn)分布式鎖呢？接著往下看！
基于Redis實(shí)現(xiàn)分布式鎖
上面分析為啥要使用分布式鎖了，這里我們來(lái)具體看看分布式鎖落地的時(shí)候應(yīng)該怎么樣處理。擴(kuò)展：Redisson是如何實(shí)現(xiàn)分布式鎖的？
最常見(jià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客戶(hù)端就不能刪除B的鎖了。
除了要考慮客戶(hù)端要怎么實(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）
- 客戶(hù)端計(jì)算建立好鎖的時(shí)間，如果建立鎖的時(shí)間小于超時(shí)時(shí)間，就算建立成功了
- 要是鎖建立失敗了，那么就依次刪除這個(gè)鎖
- 只要?jiǎng)e人建立了一把分布式鎖，你就得不斷輪詢(xún)?nèi)L試獲取鎖
但是這樣的這種算法還是頗具爭(zhēng)議的，可能還會(huì)存在不少的問(wèn)題，無(wú)法保證加鎖的過(guò)程一定正確。
另一種方式：Redisson
此外，實(shí)現(xiàn)Redis的分布式鎖，除了自己基于redis client原生api來(lái)實(shí)現(xiàn)之外，還可以使用開(kāi)源框架：Redission
Redisson是一個(gè)企業(yè)級(jí)的開(kāi)源Redis Client，也提供了分布式鎖的支持。我也非常推薦大家使用，為什么呢？
回想一下上面說(shuō)的，如果自己寫(xiě)代碼來(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ò)期，其他線(xiàn)程有可能會(huì)獲取到鎖。
這樣一來(lái)的話(huà)，第一個(gè)線(xiàn)程還沒(méi)執(zhí)行完業(yè)務(wù)邏輯，第二個(gè)線(xiàn)程進(jìn)來(lái)了也會(huì)出現(xiàn)線(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è)客戶(hù)端持有一個(gè)鎖超過(guò)了30s怎么辦？
redisson中有一個(gè)watchdog的概念，翻譯過(guò)來(lái)就是看門(mén)狗，它會(huì)在你獲取鎖之后，每隔10秒幫你把key的超時(shí)時(shí)間設(shè)為30s
這樣的話(huà)，就算一直持有鎖也不會(huì)出現(xiàn)key過(guò)期了，其他線(xiàn)程獲取到鎖的問(wèn)題了。
- redisson的“看門(mén)狗”邏輯保證了沒(méi)有死鎖發(fā)生。
(如果機(jī)器宕機(jī)了，看門(mén)狗也就沒(méi)了。此時(shí)就不會(huì)延長(zhǎng)key的過(guò)期時(shí)間，到了30s之后就會(huì)自動(dòng)過(guò)期了，其他線(xiàn)程可以獲取到鎖)
這里稍微貼出來(lái)其實(shí)現(xiàn)代碼：
- // 加鎖邏輯
- private <T> RFuture<Long> 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<Long> ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
- ttlRemainingFuture.addListener(new FutureListener<Long>() {
- @Override
- public void operationComplete(Future<Long> future) throws Exception {
- if (!future.isSuccess()) {
- return;
- }
- Long ttlRemaining = future.getNow();
- // lock acquired
- if (ttlRemaining == null) {
- // 看門(mén)狗邏輯
- scheduleExpirationRenewal(threadId);
- }
- }
- });
- return ttlRemainingFuture;
- }
- <T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> 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.<Object>singletonList(getName()), internalLockLeaseTime, getLockName(threadId));
- }
- // 看門(mén)狗最終會(huì)調(diào)用了這里
- private void scheduleExpirationRenewal(final long threadId) {
- if (expirationRenewalMap.containsKey(getEntryName())) {
- return;
- }
- // 這個(gè)任務(wù)會(huì)延遲10s執(zhí)行
- Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
- @Override
- public void run(Timeout timeout) throws Exception {
- // 這個(gè)操作會(huì)將key的過(guò)期時(shí)間重新設(shè)置為30s
- RFuture<Boolean> future = renewExpirationAsync(threadId);
- future.addListener(new FutureListener<Boolean>() {
- @Override
- public void operationComplete(Future<Boolean> future) throws Exception {
- expirationRenewalMap.remove(getEntryName());
- if (!future.isSuccess()) {
- log.error("Can't update lock " + getName() + " expiration", future.cause());
- return;
- }
- if (future.getNow()) {
- // reschedule itself
- // 通過(guò)遞歸調(diào)用本方法，無(wú)限循環(huán)延長(zhǎng)過(guò)期時(shí)間
- scheduleExpirationRenewal(threadId);
- }
- }
- });
- }
- }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
- if (expirationRenewalMap.putIfAbsent(getEntryName(), new ExpirationEntry(threadId, task)) != null) {
- task.cancel();
- }
- }
另外，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的客戶(hù)端框架redisson，
這也是我推薦大家使用的，
比自己寫(xiě)代碼實(shí)現(xiàn)會(huì)少care很多細(xì)節(jié)。
基于zookeeper實(shí)現(xiàn)分布式鎖
常見(jià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，依次類(lèi)推。
- 臨時(shí)節(jié)點(diǎn)：客戶(hù)端可以建立一個(gè)臨時(shí)節(jié)點(diǎn)，在會(huì)話(huà)結(jié)束或者會(huì)話(huà)超時(shí)后，zookeeper會(huì)自動(dòng)刪除該節(jié)點(diǎn)。
- 事件監(jiān)聽(tīng)：在讀取數(shù)據(jù)時(shí)，我們可以同時(shí)對(duì)節(jié)點(diǎn)設(shè)置事件監(jiān)聽(tīng)，當(dāng)節(jié)點(diǎn)數(shù)據(jù)或結(jié)構(gòu)變化時(shí)，zookeeper會(huì)通知客戶(hù)端。當(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è)線(xiàn)程獲取鎖就是在zk創(chuàng)建一個(gè)臨時(shí)有序的節(jié)點(diǎn)，比如在/lock/目錄下。
- 創(chuàng)建節(jié)點(diǎn)成功后，獲取/lock目錄下的所有臨時(shí)節(jié)點(diǎn)，再判斷當(dāng)前線(xiàn)程創(chuàng)建的節(jié)點(diǎn)是否是所有的節(jié)點(diǎn)的序號(hào)最小的節(jié)點(diǎn)
- 如果當(dāng)前線(xiàn)程創(chuàng)建的節(jié)點(diǎn)是所有節(jié)點(diǎn)序號(hào)最小的節(jié)點(diǎn)，則認(rèn)為獲取鎖成功。
- 如果當(dāng)前線(xiàn)程創(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)聽(tīng)。
- 比如當(dāng)前線(xiàn)程獲取到的節(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)聽(tīng)器。
如果鎖釋放了，會(huì)喚醒下一個(gè)序號(hào)的節(jié)點(diǎn)，然后重新執(zhí)行第3步，判斷是否自己的節(jié)點(diǎn)序號(hào)是最小。
比如/lock/001釋放了，/lock/002監(jiān)聽(tīng)到時(shí)間，此時(shí)節(jié)點(diǎn)集合為[/lock/002,/lock/003],則/lock/002為最小序號(hào)節(jié)點(diǎn)，獲取到鎖。
整個(gè)過(guò)程如下：
具體的實(shí)現(xiàn)思路就是這樣，至于代碼怎么寫(xiě)，這里比較復(fù)雜就不貼出來(lái)了。
Curator介紹
Curator是一個(gè)zookeeper的開(kāi)源客戶(hù)端，也提供了分布式鎖的實(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<String> children = getSortedChildren();
- // 獲取當(dāng)前節(jié)點(diǎn)的名稱(chēng)
- 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)聽(tīng)器
- 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的開(kāi)源客戶(hù)端的基本使用，簡(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ō)的話(huà)，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è)中非常常見(jiàn)，而且大部分情況下都不會(huì)遇到所謂的“極端復(fù)雜場(chǎng)景”
所以使用redis作為分布式鎖也不失為一種好的方案，最重要的一點(diǎn)是redis的性能很高，可以支撐高并發(fā)的獲取、釋放鎖操作。
對(duì)于zk分布式鎖而言:
- zookeeper天生設(shè)計(jì)定位就是分布式協(xié)調(diào)，強(qiáng)一致性。鎖的模型健壯、簡(jiǎn)單易用、適合做分布式鎖。
- 如果獲取不到鎖，只需要添加一個(gè)監(jiān)聽(tīng)器就可以了，不用一直輪詢(xún)，性能消耗較小。
但是zk也有其缺點(diǎn)：如果有較多的客戶(hù)端頻繁的申請(qǐng)加鎖、釋放鎖，對(duì)于zk集群的壓力會(huì)比較大。
小結(jié)：
綜上所述，redis和zookeeper都有其優(yōu)缺點(diǎn)。我們?cè)谧黾夹g(shù)選型的時(shí)候可以根據(jù)這些問(wèn)題作為參考因素。
建議
通過(guò)前面的分析，實(shí)現(xiàn)分布式鎖的兩種常見(jiàn)方案：redis和zookeeper，他們各有千秋。應(yīng)該如何選型呢？
就個(gè)人而言的話(huà)，我比較推崇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，但是又不希望再次引入一些外部依賴(lài)的情況下，可以選用redis。
這個(gè)是要系統(tǒng)設(shè)計(jì)者基于架構(gòu)的考慮了。
