日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
分布式鎖用Redis還是Zookeeper？

分布式鎖用Redis還是ZooKeeper？

作者：佚名 2020-11-16 12:55:41

數(shù)據(jù)庫

其他數(shù)據(jù)庫

分布式

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

 為什么用分布式鎖？

在討論這個問題之前，我們先來看一個業(yè)務(wù)場景：

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

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

此時系統(tǒng)架構(gòu)如下：

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

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

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

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

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

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

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

但是好景不長，整個系統(tǒng)的并發(fā)飆升，一臺機(jī)器扛不住了?，F(xiàn)在要增加一臺機(jī)器，如下圖：

增加機(jī)器之后，系統(tǒng)變成上圖所示，我的天！

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

為什么呢？因?yàn)樯蠄D中的兩個A系統(tǒng)，運(yùn)行在兩個不同的JVM里面，他們加的鎖只對屬于自己JVM里面的線程有效，對于其他JVM的線程是無效的。

因此，這里的問題是：Java提供的原生鎖機(jī)制在多機(jī)部署場景下失效了

這是因?yàn)閮膳_機(jī)器加的鎖不是同一個鎖(兩個鎖在不同的JVM里面)。

那么，我們只要保證兩臺機(jī)器加的鎖是同一個鎖，問題不就解決了嗎？

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

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

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

文字描述不太直觀，我們來看下圖：

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

那么，如何實(shí)現(xiàn)分布式鎖呢？接著往下看！

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

上面分析為啥要使用分布式鎖了，這里我們來具體看看分布式鎖落地的時候應(yīng)該怎么樣處理。擴(kuò)展：Redisson是如何實(shí)現(xiàn)分布式鎖的？

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

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

具體代碼是這樣的： 

  
 
 
 
    
   
  
  
  
  1. // 獲取鎖  
    2. 
   
  
  
  
  2. // NX是指如果key不存在就成功，key存在返回false，PX可以指定過期時間  
    3. 
   
  
  
  
  3. SET anyLock unique_value NX PX 30000  
    4. 
   
  
  
  
  4. // 釋放鎖：通過執(zhí)行一段lua腳本  
    5. 
   
  
  
  
  5. // 釋放鎖涉及到兩條指令，這兩條指令不是原子性的  
    6. 
   
  
  
  
  6. // 需要用到redis的lua腳本支持特性，redis執(zhí)行l(wèi)ua腳本是原子性的  
    7. 
   
  
  
  
  7. if redis.call("get",KEYS[1]) == ARGV[1] then  
    8. 
   
  
  
  
  8. return redis.call("del",KEYS[1]) 
    9. 
   
  
  
  
  9.  else  
    10. 
   
  
  
  
  10. return 0  
    11. 
   
  
  
  
  11. end 
    12.

這種方式有幾大要點(diǎn)：

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

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

  •  value要具有唯一性

    這個是為了在解鎖的時候，需要驗(yàn)證value是和加鎖的一致才刪除key。

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

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

redis有3種部署方式：

  •  單機(jī)模式
  •  master-slave + sentinel選舉模式
  •  redis cluster模式

使用redis做分布式鎖的缺點(diǎn)在于：如果采用單機(jī)部署模式，會存在單點(diǎn)問題，只要redis故障了。加鎖就不行了。

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

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

假設(shè)redis的部署模式是redis cluster，總共有5個master節(jié)點(diǎn)，通過以下步驟獲取一把鎖：

  •  獲取當(dāng)前時間戳，單位是毫秒
  •  輪流嘗試在每個master節(jié)點(diǎn)上創(chuàng)建鎖，過期時間設(shè)置較短，一般就幾十毫秒
  •  嘗試在大多數(shù)節(jié)點(diǎn)上建立一個鎖，比如5個節(jié)點(diǎn)就要求是3個節(jié)點(diǎn)（n / 2 +1）
  •  客戶端計(jì)算建立好鎖的時間，如果建立鎖的時間小于超時時間，就算建立成功了
  •  要是鎖建立失敗了，那么就依次刪除這個鎖
  •  只要別人建立了一把分布式鎖，你就得不斷輪詢?nèi)L試獲取鎖

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

另一種方式：Redisson

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

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

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

  •  SET anyLock unique_value NX PX 30000

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

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

我們來看看redisson是怎么實(shí)現(xiàn)的？先感受一下使用redission的爽： 

  
 
 
 
    
   
  
  
  
  1. Config config = new Config();  
    2. 
   
  
  
  
  2. config.useClusterServers()  
    3. 
   
  
  
  
  3. .addNodeAddress("redis://192.168.31.101:7001")  
    4. 
   
  
  
  
  4. .addNodeAddress("redis://192.168.31.101:7002")  
    5. 
   
  
  
  
  5. .addNodeAddress("redis://192.168.31.101:7003")  
    6. 
   
  
  
  
  6. .addNodeAddress("redis://192.168.31.102:7001")  
    7. 
   
  
  
  
  7. .addNodeAddress("redis://192.168.31.102:7002")  
    8. 
   
  
  
  
  8. .addNodeAddress("redis://192.168.31.102:7003");  
    9. 
   
  
  
  
  9. RedissonClient redisson = Redisson.create(config);  
    10. 
   
  
  
  
  10. RLock lock = redisson.getLock("anyLock");  
    11. 
   
  
  
  
  11. lock.lock();  
    12. 
   
  
  
  
  12. lock.unlock(); 
    13.

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

  •  redisson所有指令都通過lua腳本執(zhí)行，redis支持lua腳本原子性執(zhí)行
  •  redisson設(shè)置一個key的默認(rèn)過期時間為30s,如果某個客戶端持有一個鎖超過了30s怎么辦？

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

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

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

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

這里稍微貼出來其實(shí)現(xiàn)代碼： 

  
 
 
 
    
   
  
  
  
  1. // 加鎖邏輯  
    2. 
   
  
  
  
  2. private  RFuture tryAcquireAsync(long leaseTime, TimeUnit unit, final long threadId) {  
    3. 
   
  
  
  
  3.     if (leaseTime != -1) {  
    4. 
   
  
  
  
  4.         return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG); 
    5. 
   
  
  
  
  5.     }  
    6. 
   
  
  
  
  6.     // 調(diào)用一段lua腳本，設(shè)置一些key、過期時間  
    7. 
   
  
  
  
  7.     RFuture ttlRemainingFuture = tryLockInnerAsync(commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout(), TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG); 
    8. 
   
  
  
  
  8.      ttlRemainingFuture.addListener(new FutureListener() {  
    9. 
   
  
  
  
  9.         @Override  
    10. 
   
  
  
  
  10.         public void operationComplete(Future future) throws Exception {  
    11. 
   
  
  
  
  11.             if (!future.isSuccess()) {  
    12. 
   
  
  
  
  12.                 return;  
    13. 
   
  
  
  
  13.             }  
    14. 
   
  
  
  
  14.             Long ttlRemaining = future.getNow();  
    15. 
   
  
  
  
  15.             // lock acquired  
    16. 
   
  
  
  
  16.             if (ttlRemaining == null) {  
    17. 
   
  
  
  
  17.                 // 看門狗邏輯  
    18. 
   
  
  
  
  18.                 scheduleExpirationRenewal(threadId);  
    19. 
   
  
  
  
  19.             }  
    20. 
   
  
  
  
  20.         }  
    21. 
   
  
  
  
  21.     });  
    22. 
   
  
  
  
  22.     return ttlRemainingFuture;  
    23. 
   
  
  
  
  23. }  
    24. 
   
  
  
  
  24.  RFuture tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand command) {  
    25. 
   
  
  
  
  25.     internalLockLeaseTime = unit.toMillis(leaseTime);  
    26. 
   
  
  
  
  26.     return commandExecutor.evalWriteAsync(getName(), LongCodec.INSTANCE, command,  
    27. 
   
  
  
  
  27.               "if (redis.call('exists', KEYS[1]) == 0) then " +  
    28. 
   
  
  
  
  28.                   "redis.call('hset', KEYS[1], ARGV[2], 1); " +  
    29. 
   
  
  
  
  29.                   "redis.call('pexpire', KEYS[1], ARGV[1]); " +  
    30. 
   
  
  
  
  30.                   "return nil; " +  
    31. 
   
  
  
  
  31.               "end; " +  
    32. 
   
  
  
  
  32.               "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +  
    33. 
   
  
  
  
  33.                   "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +  
    34. 
   
  
  
  
  34.                   "redis.call('pexpire', KEYS[1], ARGV[1]); " +  
    35. 
   
  
  
  
  35.                   "return nil; " +  
    36. 
   
  
  
  
  36.               "end; " +  
    37. 
   
  
  
  
  37.               "return redis.call('pttl', KEYS[1]);",  
    38. 
   
  
  
  
  38.                 Collections.singletonList(getName()), internalLockLeaseTime, getLockName(threadId)); 
   
  
  
  
  39. }  
    40. 
   
  
  
  
  40. // 看門狗最終會調(diào)用了這里  
    41. 
   
  
  
  
  41. private void scheduleExpirationRenewal(final long threadId) {  
    42. 
   
  
  
  
  42.     if (expirationRenewalMap.containsKey(getEntryName())) {  
    43. 
   
  
  
  
  43.         return;  
    44. 
   
  
  
  
  44.     }  
    45. 
   
  
  
  
  45.     // 這個任務(wù)會延遲10s執(zhí)行  
    46. 
   
  
  
  
  46.     Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {  
    47. 
   
  
  
  
  47.         @Override  
    48. 
   
  
  
  
  48.         public void run(Timeout timeout) throws Exception {  
    49. 
   
  
  
  
  49.             // 這個操作會將key的過期時間重新設(shè)置為30s  
    50. 
   
  
  
  
  50.             RFuture future = renewExpirationAsync(threadId);  
    51. 
   
  
  
  
  51.             future.addListener(new FutureListener() {  
    52. 
   
  
  
  
  52.                 @Override  
    53. 
   
  
  
  
  53.                 public void operationComplete(Future future) throws Exception {  
    54. 
   
  
  
  
  54.                     expirationRenewalMap.remove(getEntryName());  
    55. 
   
  
  
  
  55.                     if (!future.isSuccess()) {  
    56. 
   
  
  
  
  56.                         log.error("Can't update lock " + getName() + " expiration", future.cause());  
    57. 
   
  
  
  
  57.                         return;  
    58. 
   
  
  
  
  58.                     }  
    59. 
   
  
  
  
  59.                     if (future.getNow()) {  
    60. 
   
  
  
  
  60.                         // reschedule itself  
    61. 
   
  
  
  
  61.                         // 通過遞歸調(diào)用本方法，無限循環(huán)延長過期時間  
    62. 
   
  
  
  
  62.                         scheduleExpirationRenewal(threadId);  
    63. 
   
  
  
  
  63.                     }  
    64. 
   
  
  
  
  64.                 }  
    65. 
   
  
  
  
  65.             });  
    66. 
   
  
  
  
  66.         }  
    67. 
   
  
  
  
  67.     }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);  
    68. 
   
  
  
  
  68.     if (expirationRenewalMap.putIfAbsent(getEntryName(), new ExpirationEntry(threadId, task)) != null) {  
    69. 
   
  
  
  
  69.         task.cancel();  
    70. 
   
  
  
  
  70.     }  
    71. 
   
  
  
  
  71. } 
    72. 
  
 
 
 
    另外，redisson還提供了對redlock算法的支持,
    它的用法也很簡單： 
      
 
 
 
      
   
  
  
  
    1. RedissonClient redisson = Redisson.create(config);  
      2. 
   
  
  
  
    2. RLock lock1 = redisson.getFairLock("lock1");  
      3. 
   
  
  
  
    3. RLock lock2 = redisson.getFairLock("lock2");  
      4. 
   
  
  
  
    4. RLock lock3 = redisson.getFairLock("lock3");  
      5. 
   
  
  
  
    5. RedissonRedLock multiLock = new RedissonRedLock(lock1, lock2, lock3);  
      6. 
   
  
  
  
    6. multiLock.lock();  
      7. 
   
  
  
  
    7. multiLock.unlock(); 
      8. 
  
 
 
 
    小結(jié)：
    本節(jié)分析了使用redis作為分布式鎖的具體落地方案
    以及其一些局限性
    然后介紹了一個redis的客戶端框架redisson，
    這也是我推薦大家使用的，
    比自己寫代碼實(shí)現(xiàn)會少care很多細(xì)節(jié)。
    基于zookeeper實(shí)現(xiàn)分布式鎖
    常見的分布式鎖實(shí)現(xiàn)方案里面，除了使用redis來實(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)一樣每個znode表示一個目錄，然后znode有一些特性：
      

    •  有序節(jié)點(diǎn)：假如當(dāng)前有一個父節(jié)點(diǎn)為/lock，我們可以在這個父節(jié)點(diǎn)下面創(chuàng)建子節(jié)點(diǎn)；
      • 

    

              zookeeper提供了一個可選的有序特性，例如我們可以創(chuàng)建子節(jié)點(diǎn)“/lock/node-”并且指明有序，那么zookeeper在生成子節(jié)點(diǎn)時會根據(jù)當(dāng)前的子節(jié)點(diǎn)數(shù)量自動添加整數(shù)序號
              也就是說，如果是第一個創(chuàng)建的子節(jié)點(diǎn)，那么生成的子節(jié)點(diǎn)為/lock/node-0000000000，下一個節(jié)點(diǎn)則為/lock/node-0000000001，依次類推。
      

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

    •  事件監(jiān)聽：在讀取數(shù)據(jù)時，我們可以同時對節(jié)點(diǎn)設(shè)置事件監(jiān)聽，當(dāng)節(jié)點(diǎn)數(shù)據(jù)或結(jié)構(gòu)變化時，zookeeper會通知客戶端。當(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的臨時節(jié)點(diǎn)和有序節(jié)點(diǎn)，每個線程獲取鎖就是在zk創(chuàng)建一個臨時有序的節(jié)點(diǎn)，比如在/lock/目錄下。
      2. 

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

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

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

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

    

    如果鎖釋放了，會喚醒下一個序號的節(jié)點(diǎn)，然后重新執(zhí)行第3步，判斷是否自己的節(jié)點(diǎn)序號是最小。
    比如/lock/001釋放了，/lock/002監(jiān)聽到時間，此時節(jié)點(diǎn)集合為[/lock/002,/lock/003],則/lock/002為最小序號節(jié)點(diǎn)，獲取到鎖。
    整個過程如下：
    具體的實(shí)現(xiàn)思路就是這樣，至于代碼怎么寫，這里比較復(fù)雜就不貼出來了。
    Curator介紹
    Curator是一個zookeeper的開源客戶端，也提供了分布式鎖的實(shí)現(xiàn)。
    他的使用方式也比較簡單： 
      
 
 
 
      
   
  
  
  
    1. InterProcessMutex interProcessMutex = new InterProcessMutex(client,"/anyLock");  
      2. 
   
  
  
  
    2. interProcessMutex.acquire();  
      3. 
   
  
  
  
    3. interProcessMutex.release(); 
      4. 
  
 
 
 
    其實(shí)現(xiàn)分布式鎖的核心源碼如下： 
      
 
 
 
      
   
  
  
  
    1. private boolean internalLockLoop(long startMillis, Long millisToWait, String ourPath) throws Exception  
      2. 
   
  
  
  
    2. {  
      3. 
   
  
  
  
    3.     boolean  haveTheLock = false;  
      4. 
   
  
  
  
    4.     boolean  doDelete = false;  
      5. 
   
  
  
  
    5.     try {  
      6. 
   
  
  
  
    6.         if ( revocable.get() != null ) {  
      7. 
   
  
  
  
    7.             client.getData().usingWatcher(revocableWatcher).forPath(ourPath);  
      8. 
   
  
  
  
    8.         }  
      9. 
   
  
  
  
    9.         while ( (client.getState() == CuratorFrameworkState.STARTED) && !haveTheLock ) {  
      10. 
   
  
  
  
    10.             // 獲取當(dāng)前所有節(jié)點(diǎn)排序后的集合  
      11. 
   
  
  
  
    11.             List        children = getSortedChildren();  
      12. 
   
  
  
  
    12.             // 獲取當(dāng)前節(jié)點(diǎn)的名稱  
      13. 
   
  
  
  
    13.             String              sequenceNodeName = ourPath.substring(basePath.length() + 1); // +1 to include the slash  
      14. 
   
  
  
  
    14.             // 判斷當(dāng)前節(jié)點(diǎn)是否是最小的節(jié)點(diǎn)  
      15. 
   
  
  
  
    15.             PredicateResults    predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases);  
      16. 
   
  
  
  
    16.             if ( predicateResults.getsTheLock() ) {  
      17. 
   
  
  
  
    17.                 // 獲取到鎖  
      18. 
   
  
  
  
    18.                 haveTheLock = true;  
      19. 
   
  
  
  
    19.             } else {  
      20. 
   
  
  
  
    20.                 // 沒獲取到鎖，對當(dāng)前節(jié)點(diǎn)的上一個節(jié)點(diǎn)注冊一個監(jiān)聽器  
      21. 
   
  
  
  
    21.                 String  previousSequencePath = basePath + "/" + predicateResults.getPathToWatch();  
      22. 
   
  
  
  
    22.                 synchronized(this){ 
      23. 
   
  
  
  
    23.                      Stat stat = client.checkExists().usingWatcher(watcher).forPath(previousSequencePath);  
      24. 
   
  
  
  
    24.                     if ( stat != null ){  
      25. 
   
  
  
  
    25.                         if ( millisToWait != null ){  
      26. 
   
  
  
  
    26.                             millisToWait -= (System.currentTimeMillis() - startMillis);  
      27. 
   
  
  
  
    27.                             startMillis = System.currentTimeMillis();  
      28. 
   
  
  
  
    28.                             if ( millisToWait <= 0 ){  
      29. 
   
  
  
  
    29.                                 doDelete = true;    // timed out - delete our node  
      30. 
   
  
  
  
    30.                                 break;  
      31. 
   
  
  
  
    31.                             } 
      32. 
   
  
  
  
    32.                              wait(millisToWait);  
      33. 
   
  
  
  
    33.                         }else{  
      34. 
   
  
  
  
    34.                             wait();  
      35. 
   
  
  
  
    35.                         }  
      36. 
   
  
  
  
    36.                     }  
      37. 
   
  
  
  
    37.                 }  
      38. 
   
  
  
  
    38.                 // else it may have been deleted (i.e. lock released). Try to acquire again  
      39. 
   
  
  
  
    39.             }  
      40. 
   
  
  
  
    40.         } 
      41. 
   
  
  
  
    41.      }  
      42. 
   
  
  
  
    42.     catch ( Exception e ) {  
      43. 
   
  
  
  
    43.         doDelete = true;  
      44. 
   
  
  
  
    44.         throw e;  
      45. 
   
  
  
  
    45.     } finally{  
      46. 
   
  
  
  
    46.         if ( doDelete ){  
      47. 
   
  
  
  
    47.             deleteOurPath(ourPath);  
      48. 
   
  
  
  
    48.         }  
      49. 
   
  
  
  
    49.     }  
      50. 
   
  
  
  
    50.     return haveTheLock;  
      51. 
   
  
  
  
    51. } 
      52. 
  
 
 
 
    其實(shí)curator實(shí)現(xiàn)分布式鎖的底層原理和上面分析的是差不多的。這里我們用一張圖詳細(xì)描述其原理：
    小結(jié)：
    本節(jié)介紹了zookeeperr實(shí)現(xiàn)分布式鎖的方案以及zk的開源客戶端的基本使用，簡要的介紹了其實(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)。
    對于redis的分布式鎖而言，它有以下缺點(diǎn)：
      

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

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

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

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

    

    但是另一方面使用redis實(shí)現(xiàn)分布式鎖在很多企業(yè)中非常常見，而且大部分情況下都不會遇到所謂的“極端復(fù)雜場景”
    所以使用redis作為分布式鎖也不失為一種好的方案，最重要的一點(diǎn)是redis的性能很高，可以支撐高并發(fā)的獲取、釋放鎖操作。
    對于zk分布式鎖而言:
      

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

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

    

    但是zk也有其缺點(diǎn)：如果有較多的客戶端頻繁的申請加鎖、釋放鎖，對于zk集群的壓力會比較大。
    小結(jié)：
    綜上所述，redis和zookeeper都有其優(yōu)缺點(diǎn)。我們在做技術(shù)選型的時候可以根據(jù)這些問題作為參考因素。
    建議
    通過前面的分析，實(shí)現(xiàn)分布式鎖的兩種常見方案：redis和zookeeper，他們各有千秋。應(yīng)該如何選型呢？
    就個人而言的話，我比較推崇zk實(shí)現(xiàn)的鎖：
    因?yàn)閞edis是有可能存在隱患的，可能會導(dǎo)致數(shù)據(jù)不對的情況。但是，怎么選用要看具體在公司的場景了。
    如果公司里面有zk集群條件，優(yōu)先選用zk實(shí)現(xiàn)，但是如果說公司里面只有redis集群，沒有條件搭建zk集群。
    那么其實(shí)用redis來實(shí)現(xiàn)也可以，另外還可能是系統(tǒng)設(shè)計(jì)者考慮到了系統(tǒng)已經(jīng)有redis，但是又不希望再次引入一些外部依賴的情況下，可以選用redis。
    這個是要系統(tǒng)設(shè)計(jì)者基于架構(gòu)的考慮了。
                                                    
    
                                                網(wǎng)站題目：分布式鎖用Redis還是Zookeeper？                                                
    
                                                文章路徑：http://www.dlmjj.cn/article/cdjggpo.html