<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          分布式鎖用 Redis 還是 Zookeeper?

          共 9623字,需瀏覽 20分鐘

           ·

          2022-04-10 20:31

          為什么用分布式鎖?

          在討論這個(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.singletonList(getName()),?internalLockLeaseTime,?getLockName(threadId));
          }



          //?看門狗最終會(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?future?=?renewExpirationAsync(threadId);

          ????????????future.addListener(new?FutureListener()?{
          ????????????????@Override
          ????????????????public?void?operationComplete(Future?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的客戶端框架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)分布式鎖的落地方案:

          1. 使用zk的臨時(shí)節(jié)點(diǎn)和有序節(jié)點(diǎn),每個(gè)線程獲取鎖就是在zk創(chuàng)建一個(gè)臨時(shí)有序的節(jié)點(diǎn),比如在/lock/目錄下。

          2. 創(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)

          3. 如果當(dāng)前線程創(chuàng)建的節(jié)點(diǎn)是所有節(jié)點(diǎn)序號(hào)最小的節(jié)點(diǎn),則認(rèn)為獲取鎖成功。

          4. 如果當(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ú)窮極。

          瀏覽 28
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                    <th id="afajh"><progress id="afajh"></progress></th>
                    色情片免费观看 | 蜜芽AV久久 | 亚州精品无码视频 | 嗯~公啊~嗯~挺进啊~A片视频 | 日本一区二区中文字幕 |