<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?

          共 20948字,需瀏覽 42分鐘

           ·

          2021-05-10 19:13


          點擊上方“碼農(nóng)突圍”,馬上關注
          這里是碼農(nóng)充電第一站,回復“666”,獲取一份專屬大禮包
          真愛,請設置“星標”或點個“在看”

          作者:jianfeng

          來源:石杉的架構筆記

          為什么用分布式鎖?

          在討論這個問題之前,我們先來看一個業(yè)務場景:

          系統(tǒng)A是一個電商系統(tǒng),目前是一臺機器部署,系統(tǒng)中有一個用戶下訂單的接口,但是用戶下訂單之前一定要去檢查一下庫存,確保庫存足夠了才會給用戶下單。

          由于系統(tǒng)有一定的并發(fā),所以會預先將商品的庫存保存在redis中,用戶下單的時候會更新redis的庫存。

          此時系統(tǒng)架構如下:

          但是這樣一來會產(chǎn)生一個問題:假如某個時刻,redis里面的某個商品庫存為1,此時兩個請求同時到來,其中一個請求執(zhí)行到上圖的第3步,更新數(shù)據(jù)庫的庫存為0,但是第4步還沒有執(zhí)行。

          而另外一個請求執(zhí)行到了第2步,發(fā)現(xiàn)庫存還是1,就繼續(xù)執(zhí)行第3步。

          這樣的結(jié)果,是導致賣出了2個商品,然而其實庫存只有1個。

          明顯不對啊!這就是典型的庫存超賣問題

          此時,我們很容易想到解決方案:用鎖把2、3、4步鎖住,讓他們執(zhí)行完之后,另一個線程才能進來執(zhí)行第2步。

          按照上面的圖,在執(zhí)行第2步時,使用Java提供的synchronized或者ReentrantLock來鎖住,然后在第4步執(zhí)行完之后才釋放鎖。

          這樣一來,2、3、4 這3個步驟就被“鎖”住了,多個線程之間只能串行化執(zhí)行。

          但是好景不長,整個系統(tǒng)的并發(fā)飆升,一臺機器扛不住了。現(xiàn)在要增加一臺機器,如下圖:


          增加機器之后,系統(tǒng)變成上圖所示,我的天!

          假設此時兩個用戶的請求同時到來,但是落在了不同的機器上,那么這兩個請求是可以同時執(zhí)行了,還是會出現(xiàn)庫存超賣的問題。

          為什么呢?因為上圖中的兩個A系統(tǒng),運行在兩個不同的JVM里面,他們加的鎖只對屬于自己JVM里面的線程有效,對于其他JVM的線程是無效的。

          因此,這里的問題是:Java提供的原生鎖機制在多機部署場景下失效了

          這是因為兩臺機器加的鎖不是同一個鎖(兩個鎖在不同的JVM里面)。

          那么,我們只要保證兩臺機器加的鎖是同一個鎖,問題不就解決了嗎?

          此時,就該分布式鎖隆重登場了,分布式鎖的思路是:

          在整個系統(tǒng)提供一個全局、唯一的獲取鎖的“東西”,然后每個系統(tǒng)在需要加鎖時,都去問這個“東西”拿到一把鎖,這樣不同的系統(tǒng)拿到的就可以認為是同一把鎖。

          至于這個“東西”,可以是Redis、Zookeeper,也可以是數(shù)據(jù)庫。

          文字描述不太直觀,我們來看下圖:

          通過上面的分析,我們知道了庫存超賣場景在分布式部署系統(tǒng)的情況下使用Java原生的鎖機制無法保證線程安全,所以我們需要用到分布式鎖的方案。

          那么,如何實現(xiàn)分布式鎖呢?接著往下看!

          基于Redis實現(xiàn)分布式鎖

          上面分析為啥要使用分布式鎖了,這里我們來具體看看分布式鎖落地的時候應該怎么樣處理。擴展:Redisson是如何實現(xiàn)分布式鎖的?


          最常見的一種方案就是使用Redis做分布式鎖

          使用Redis做分布式鎖的思路大概是這樣的:在redis中設置一個值表示加了鎖,然后釋放鎖的時候就把這個key刪除。

          具體代碼是這樣的:

          // 獲取鎖
          // NX是指如果key不存在就成功,key存在返回false,PX可以指定過期時間
          SET anyLock unique_value NX PX 30000


          // 釋放鎖:通過執(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


          這種方式有幾大要點:

          • 一定要用SET key value NX PX milliseconds 命令

            如果不用,先設置了值,再設置過期時間,這個不是原子性操作,有可能在設置過期時間之前宕機,會造成死鎖(key永久存在)

          • value要具有唯一性

            這個是為了在解鎖的時候,需要驗證value是和加鎖的一致才刪除key。

            這是避免了一種情況:假設A獲取了鎖,過期時間30s,此時35s之后,鎖已經(jīng)自動釋放了,A去釋放鎖,但是此時可能B獲取了鎖。A客戶端就不能刪除B的鎖了。

          除了要考慮客戶端要怎么實現(xiàn)分布式鎖之外,還需要考慮redis的部署問題。

          redis有3種部署方式:

          • 單機模式

          • master-slave + sentinel選舉模式

          • redis cluster模式


          使用redis做分布式鎖的缺點在于:如果采用單機部署模式,會存在單點問題,只要redis故障了。加鎖就不行了。

          采用master-slave模式,加鎖的時候只對一個節(jié)點加鎖,即便通過sentinel做了高可用,但是如果master節(jié)點故障了,發(fā)生主從切換,此時就會有可能出現(xiàn)鎖丟失的問題。

          基于以上的考慮,其實redis的作者也考慮到這個問題,他提出了一個RedLock的算法,這個算法的意思大概是這樣的:

          假設redis的部署模式是redis cluster,總共有5個master節(jié)點,通過以下步驟獲取一把鎖:

          • 獲取當前時間戳,單位是毫秒

          • 輪流嘗試在每個master節(jié)點上創(chuàng)建鎖,過期時間設置較短,一般就幾十毫秒

          • 嘗試在大多數(shù)節(jié)點上建立一個鎖,比如5個節(jié)點就要求是3個節(jié)點(n / 2 +1)

          • 客戶端計算建立好鎖的時間,如果建立鎖的時間小于超時時間,就算建立成功了

          • 要是鎖建立失敗了,那么就依次刪除這個鎖

          • 只要別人建立了一把分布式鎖,你就得不斷輪詢?nèi)L試獲取鎖


          但是這樣的這種算法還是頗具爭議的,可能還會存在不少的問題,無法保證加鎖的過程一定正確。

          另一種方式:Redisson

          此外,實現(xiàn)Redis的分布式鎖,除了自己基于redis client原生api來實現(xiàn)之外,還可以使用開源框架:Redission

          Redisson是一個企業(yè)級的開源Redis Client,也提供了分布式鎖的支持。我也非常推薦大家使用,為什么呢?

          回想一下上面說的,如果自己寫代碼來通過redis設置一個值,是通過下面這個命令設置的。

          • SET anyLock unique_value NX PX 30000

          這里設置的超時時間是30s,假如我超過30s都還沒有完成業(yè)務邏輯的情況下,key會過期,其他線程有可能會獲取到鎖。

          這樣一來的話,第一個線程還沒執(zhí)行完業(yè)務邏輯,第二個線程進來了也會出現(xiàn)線程安全問題。所以我們還需要額外的去維護這個過期時間,太麻煩了~

          我們來看看redisson是怎么實現(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();


          就是這么簡單,我們只需要通過它的api中的lock和unlock即可完成分布式鎖,他幫我們考慮了很多細節(jié):

          • redisson所有指令都通過lua腳本執(zhí)行,redis支持lua腳本原子性執(zhí)行

          • redisson設置一個key的默認過期時間為30s,如果某個客戶端持有一個鎖超過了30s怎么辦?

            redisson中有一個watchdog的概念,翻譯過來就是看門狗,它會在你獲取鎖之后,每隔10秒幫你把key的超時時間設為30s

            這樣的話,就算一直持有鎖也不會出現(xiàn)key過期了,其他線程獲取到鎖的問題了。

          • redisson的“看門狗”邏輯保證了沒有死鎖發(fā)生。

            (如果機器宕機了,看門狗也就沒了。此時就不會延長key的過期時間,到了30s之后就會自動過期了,其他線程可以獲取到鎖)

          這里稍微貼出來其實現(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腳本,設置一些key、過期時間
              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) {
                          // 看門狗邏輯
                          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));
          }



          // 看門狗最終會調(diào)用了這里
          private void scheduleExpirationRenewal(final long threadId) {
              if (expirationRenewalMap.containsKey(getEntryName())) {
                  return;
              }

              // 這個任務會延遲10s執(zhí)行
              Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
                  @Override
                  public void run(Timeout timeout) throws Exception {

                      // 這個操作會將key的過期時間重新設置為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
                                  // 通過遞歸調(diào)用本方法,無限循環(huán)延長過期時間
                                  scheduleExpirationRenewal(threadId);
                              }
                          }
                      });
                  }

              }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);

              if (expirationRenewalMap.putIfAbsent(getEntryName(), new ExpirationEntry(threadId, task)) != null) {
                  task.cancel();
              }
          }


          另外,redisson還提供了對redlock算法的支持,

          它的用法也很簡單:

          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作為分布式鎖的具體落地方

          以及其一些局限性

          然后介紹了一個redis的客戶端框架redisson,

          這也是我推薦大家使用的,

          比自己寫代碼實現(xiàn)會少care很多細節(jié)。

          基于zookeeper實現(xiàn)分布式鎖


          常見的分布式鎖實現(xiàn)方案里面,除了使用redis來實現(xiàn)之外,使用zookeeper也可以實現(xiàn)分布式鎖。

          在介紹zookeeper(下文用zk代替)實現(xiàn)分布式鎖的機制之前,先粗略介紹一下zk是什么東西:

          Zookeeper是一種提供配置管理、分布式協(xié)同以及命名的中心化服務。

          zk的模型是這樣的:zk包含一系列的節(jié)點,叫做znode,就好像文件系統(tǒng)一樣每個znode表示一個目錄,然后znode有一些特性:

          • 有序節(jié)點:假如當前有一個父節(jié)點為/lock,我們可以在這個父節(jié)點下面創(chuàng)建子節(jié)點;

            zookeeper提供了一個可選的有序特性,例如我們可以創(chuàng)建子節(jié)點“/lock/node-”并且指明有序,那么zookeeper在生成子節(jié)點時會根據(jù)當前的子節(jié)點數(shù)量自動添加整數(shù)序號

            也就是說,如果是第一個創(chuàng)建的子節(jié)點,那么生成的子節(jié)點為/lock/node-0000000000,下一個節(jié)點則為/lock/node-0000000001,依次類推。


          • 臨時節(jié)點:客戶端可以建立一個臨時節(jié)點,在會話結(jié)束或者會話超時后,zookeeper會自動刪除該節(jié)點。

          • 事件監(jiān)聽:在讀取數(shù)據(jù)時,我們可以同時對節(jié)點設置事件監(jiān)聽,當節(jié)點數(shù)據(jù)或結(jié)構變化時,zookeeper會通知客戶端。當前zookeeper有如下四種事件:

            • 節(jié)點創(chuàng)建

            • 節(jié)點刪除

            • 節(jié)點數(shù)據(jù)修改

            • 子節(jié)點變更

          基于以上的一些zk的特性,我們很容易得出使用zk實現(xiàn)分布式鎖的落地方案:

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

          2. 創(chuàng)建節(jié)點成功后,獲取/lock目錄下的所有臨時節(jié)點,再判斷當前線程創(chuàng)建的節(jié)點是否是所有的節(jié)點的序號最小的節(jié)點

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

          4. 如果當前線程創(chuàng)建的節(jié)點不是所有節(jié)點序號最小的節(jié)點,則對節(jié)點序號的前一個節(jié)點添加一個事件監(jiān)聽。

            比如當前線程獲取到的節(jié)點序號為/lock/003,然后所有的節(jié)點列表為[/lock/001,/lock/002,/lock/003],則對/lock/002這個節(jié)點添加一個事件監(jiān)聽器。


          如果鎖釋放了,會喚醒下一個序號的節(jié)點,然后重新執(zhí)行第3步,判斷是否自己的節(jié)點序號是最小。

          比如/lock/001釋放了,/lock/002監(jiān)聽到時間,此時節(jié)點集合為[/lock/002,/lock/003],則/lock/002為最小序號節(jié)點,獲取到鎖。


          整個過程如下:

          具體的實現(xiàn)思路就是這樣,至于代碼怎么寫,這里比較復雜就不貼出來了。


          Curator介紹

          Curator是一個zookeeper的開源客戶端,也提供了分布式鎖的實現(xiàn)。

          他的使用方式也比較簡單:

          InterProcessMutex interProcessMutex = new InterProcessMutex(client,"/anyLock");
          interProcessMutex.acquire();
          interProcessMutex.release();


          其實現(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 ) {
                      // 獲取當前所有節(jié)點排序后的集合
                      List<String>        children = getSortedChildren();
                      // 獲取當前節(jié)點的名稱
                      String              sequenceNodeName = ourPath.substring(basePath.length() + 1); // +1 to include the slash
                      // 判斷當前節(jié)點是否是最小的節(jié)點
                      PredicateResults    predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);
                      if ( predicateResults.getsTheLock() ) {
                          // 獲取到鎖
                          haveTheLock = true;
                      } else {
                          // 沒獲取到鎖,對當前節(jié)點的上一個節(jié)點注冊一個監(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;
          }


          實curator實現(xiàn)分布式鎖的底層原理和上面分析的是差不多的。這里我們用一張圖詳細描述其原理:

          小結(jié):

          本節(jié)介紹了zookeeperr實現(xiàn)分布式鎖的方案以及zk的開源客戶端的基本使用,簡要的介紹了其實現(xiàn)原理。相關可以參考:肝一下ZooKeeper實現(xiàn)分布式鎖的方案,附帶實例!

          兩種方案的優(yōu)缺點比較

          學完了兩種分布式鎖的實現(xiàn)方案之后,本節(jié)需要討論的是redis和zk的實現(xiàn)方案中各自的優(yōu)缺點。

          對于redis的分布式鎖而言,它有以下缺點:

          • 它獲取鎖的方式簡單粗暴,獲取不到鎖直接不斷嘗試獲取鎖,比較消耗性能。

          • 另外來說的話,redis的設計定位決定了它的數(shù)據(jù)并不是強一致性的,在某些極端情況下,可能會出現(xiàn)問題。鎖的模型不夠健壯

          • 即便使用redlock算法來實現(xiàn),在某些復雜場景下,也無法保證其實現(xiàn)100%沒有問題,關于redlock的討論可以看How to do distributed locking

          • redis分布式鎖,其實需要自己不斷去嘗試獲取鎖,比較消耗性能。


          但是另一方面使用redis實現(xiàn)分布式鎖在很多企業(yè)中非常常見,而且大部分情況下都不會遇到所謂的“極端復雜場景”

          所以使用redis作為分布式鎖也不失為一種好的方案,最重要的一點是redis的性能很高,可以支撐高并發(fā)的獲取、釋放鎖操作。


          對于zk分布式鎖而言:

          • zookeeper天生設計定位就是分布式協(xié)調(diào),強一致性。鎖的模型健壯、簡單易用、適合做分布式鎖。

          • 如果獲取不到鎖,只需要添加一個監(jiān)聽器就可以了,不用一直輪詢,性能消耗較小。


          但是zk也有其缺點:果有較多的客戶端頻繁的申請加鎖、釋放鎖,對于zk集群的壓力會比較大。


          小結(jié):

          綜上所述,redis和zookeeper都有其優(yōu)缺點。我們在做技術選型的時候可以根據(jù)這些問題作為參考因素。

          建議

          通過前面的分析,實現(xiàn)分布式鎖的兩種常見方案:redis和zookeeper,他們各有千秋。應該如何選型呢?

          就個人而言的話,我比較推崇zk實現(xiàn)的鎖:

          因為redis是有可能存在隱患的,可能會導致數(shù)據(jù)不對的情況。但是,怎么選用要看具體在公司的場景了。

          如果公司里面有zk集群條件,優(yōu)先選用zk實現(xiàn),但是如果說公司里面只有redis集群,沒有條件搭建zk集群。

          那么其實用redis來實現(xiàn)也可以,另外還可能是系統(tǒng)設計者考慮到了系統(tǒng)已經(jīng)有redis,但是又不希望再次引入一些外部依賴的情況下,可以選用redis。

          這個是要系統(tǒng)設計者基于架構的考慮了。


          - END -

          最近熱文

          ?  再見深圳!我要去成都搞IT了!
          ? 一個員工的離職成本到底有多恐怖!
          ? 和幾個大佬吃飯,聊了他們年收入,嚇尿我了!
          ? 都說 HashMap 是線程不安全的,到底體現(xiàn)在哪兒?


          瀏覽 76
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <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>
                  艹逼影院 | 免费国产污网站 | 日韩综合欧美a在线 | 久久福利视频精品 | 成人AV资源站 |