|
為什么用分布式鎖？在討論這個(gè)問(wèn)題之前，我們先來(lái)看一個(gè)業(yè)務(wù)場(chǎng)景。 圖片來(lái)自 Pexels 為什么用分布式鎖？ 系統(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 步還沒有執(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ī)器扛不住了?，F(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)該怎么樣處理。 ①常見的一種方案就是使用 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)：
這時(shí)避免了一種情況：假設(shè) A 獲取了鎖，過(guò)期時(shí)間 30s，此時(shí) 35s 之后，鎖已經(jīng)自動(dòng)釋放了，A 去釋放鎖，但是此時(shí)可能 B 獲取了鎖。A 客戶端就不能刪除 B 的鎖了。 除了要考慮客戶端要怎么實(shí)現(xiàn)分布式鎖之外，還需要考慮 Redis 的部署問(wèn)題。 Redis 有 3 種部署方式：
使用 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)題。 基于以上的考慮，Redis 的作者也考慮到這個(gè)問(wèn)題，他提出了一個(gè) RedLock 的算法。 這個(gè)算法的意思大概是這樣的：假設(shè) Redis 的部署模式是 Redis Cluster，總共有 5 個(gè) Master 節(jié)點(diǎn)。 通過(guò)以下步驟獲取一把鎖：
但是這樣的這種算法還是頗具爭(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 都還沒有完成業(yè)務(wù)邏輯的情況下，Key 會(huì)過(guò)期，其他線程有可能會(huì)獲取到鎖。 這樣一來(lái)的話，第一個(gè)線程還沒執(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é)：
這樣的話，就算一直持有鎖也不會(huì)出現(xiàn) Key 過(guò)期了，其他線程獲取到鎖的問(wè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) { // 看門狗邏輯 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)); } // 看門狗最終會(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 的客戶端框架 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 是什么東西：ZK 是一種提供配置管理、分布式協(xié)同以及命名的中心化服務(wù)。 ZK 的模型是這樣的：ZK 包含一系列的節(jié)點(diǎn)，叫做 Znode，就好像文件系統(tǒng)一樣，每個(gè) Znode 表示一個(gè)目錄。 然后 Znode 有一些特性：
例如我們可以創(chuàng)建子節(jié)點(diǎn)“/lock/node-”并且指明有序，那么 ZK 在生成子節(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，依次類推。
當(dāng)前 ZK 有如下四種事件：
基于以上的一些 ZK 的特性，我們很容易得出使用 ZK 實(shí)現(xià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è) ZK 的開源客戶端，也提供了分布式鎖的實(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)的名稱 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 { // 沒獲取到鎖，對(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é)介紹了 ZK 實(shí)現(xiàn)分布式鎖的方案以及 ZK 的開源客戶端的基本使用，簡(jiǎn)要的介紹了其實(shí)現(xiàn)原理。 兩種方案的優(yōu)缺點(diǎn)比較 學(xué)完了兩種分布式鎖的實(shí)現(xiàn)方案之后，本節(jié)需要討論的是 Redis 和 ZK 的實(shí)現(xiàn)方案中各自的優(yōu)缺點(diǎn)。 對(duì)于 Redis 的分布式鎖而言，它有以下缺點(diǎn)：
但是另一方面使用 Redis 實(shí)現(xiàn)分布式鎖在很多企業(yè)中非常常見，而且大部分情況下都不會(huì)遇到所謂的“極端復(fù)雜場(chǎng)景”。 所以使用 Redis 作為分布式鎖也不失為一種好的方案，最重要的一點(diǎn)是 Redis 的性能很高，可以支撐高并發(fā)的獲取、釋放鎖操作。 對(duì)于 ZK 分布式鎖而言:
但是 ZK 也有其缺點(diǎn)：如果有較多的客戶端頻繁的申請(qǐng)加鎖、釋放鎖，對(duì)于 ZK 集群的壓力會(huì)比較大。 小結(jié)：綜上所述，Redis 和 ZK 都有其優(yōu)缺點(diǎn)。我們?cè)谧黾夹g(shù)選型的時(shí)候可以根據(jù)這些問(wèn)題作為參考因素。 一些建議 通過(guò)前面的分析，實(shí)現(xiàn)分布式鎖的兩種常見方案：Redis 和 ZK，他們各有千秋。應(yīng)該如何選型呢？ 就個(gè)人而言的話，我比較推崇 ZK 實(shí)現(xiàn)的鎖：因?yàn)?Redis 是有可能存在隱患的，可能會(huì)導(dǎo)致數(shù)據(jù)不對(duì)的情況。但是，怎么選用要看具體在公司的場(chǎng)景了。 如果公司里面有 ZK 集群條件，優(yōu)先選用 ZK 實(shí)現(xiàn)，但是如果說(shuō)公司里面只有 Redis 集群，沒有條件搭建 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)來(lái)考慮了。 |
|
|
來(lái)自： 學(xué)而生之 > 《人生理解和人性的認(rèn)識(shí)》
