使用Redis 或Zookeeper實現分散式鎖
最近在微信公眾號上看到一篇名為《分散式鎖用Redis還是Zookeeper?》的文章,感覺作者總結的很不錯,於是轉載過來,以便和大家一起學習!
為什麼用分散式鎖?
在討論這個問題之前,我們先來看一個業務場景:
系統A是一個電商系統,目前是一臺機器部署,系統中有一個使用者下訂單的介面,但是使用者下訂單之前一定要去檢查一下庫存,確保庫存足夠了才會給使用者下單。
由於系統有一定的併發,所以會預先將商品的庫存儲存在redis中,使用者下單的時候會更新redis的庫存。
此時系統架構如下:
但是這樣一來會產生一個問題:假如某個時刻,redis裡面的某個商品庫存為1,此時兩個請求同時到來,其中一個請求執行到上圖的第3步,更新資料庫的庫存為0,但是第4步還沒有執行。
而另外一個請求執行到了第2步,發現庫存還是1,就繼續執行第3步。
這樣的結果,是導致賣出了2個商品,然而其實庫存只有1個。
很明顯不對啊!這就是典型的庫存超賣問題
此時,我們很容易想到解決方案:用鎖把2、3、4步鎖住,讓他們執行完之後,另一個執行緒才能進來執行第2步。
按照上面的圖,在執行第2步時,使用Java提供的synchronized或者ReentrantLock來鎖住,然後在第4步執行完之後才釋放鎖。
這樣一來,2、3、4 這3個步驟就被“鎖”住了,多個執行緒之間只能序列化執行。
但是好景不長,整個系統的併發飆升,一臺機器扛不住了。現在要增加一臺機器,如下圖:
增加機器之後,系統變成上圖所示,我的天!
假設此時兩個使用者的請求同時到來,但是落在了不同的機器上,那麼這兩個請求是可以同時執行了,還是會出現庫存超賣的問題。
為什麼呢?因為上圖中的兩個A系統,執行在兩個不同的JVM裡面,他們加的鎖只對屬於自己JVM裡面的執行緒有效,對於其他JVM的執行緒是無效的。
因此,這裡的問題是:Java提供的原生鎖機制在多機部署場景下失效了
這是因為兩臺機器加的鎖不是同一個鎖(兩個鎖在不同的JVM裡面)。
那麼,我們只要保證兩臺機器加的鎖是同一個鎖,問題不就解決了嗎?
此時,就該分散式鎖隆重登場了,分散式鎖的思路是:
在整個系統提供一個全域性、唯一的獲取鎖的“東西”,然後每個系統在需要加鎖時,都去問這個“東西”拿到一把鎖,這樣不同的系統拿到的就可以認為是同一把鎖。
至於這個“東西”,可以是Redis、Zookeeper,也可以是資料庫。
文字描述不太直觀,我們來看下圖:
通過上面的分析,我們知道了庫存超賣場景在分散式部署系統的情況下使用Java原生的鎖機制無法保證執行緒安全,所以我們需要用到分散式鎖的方案。
那麼,如何實現分散式鎖呢?接著往下看!
基於Redis實現分散式鎖
上面分析為啥要使用分散式鎖了,這裡我們來具體看看分散式鎖落地的時候應該怎麼樣處理。
最常見的一種方案就是使用Redis做分散式鎖
使用Redis做分散式鎖的思路大概是這樣的:在redis中設定一個值表示加了鎖,然後釋放鎖的時候就把這個key刪除。
具體程式碼是這樣的:
// 獲取鎖 // NX是指如果key不存在就成功,key存在返回false,PX可以指定過期時間 SET anyLock unique_value NX PX 30000 // 釋放鎖:通過執行一段lua指令碼 // 釋放鎖涉及到兩條指令,這兩條指令不是原子性的 // 需要用到redis的lua指令碼支援特性,redis執行lua指令碼是原子性的 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之後,鎖已經自動釋放了,A去釋放鎖,但是此時可能B獲取了鎖。A客戶端就不能刪除B的鎖了。
除了要考慮客戶端要怎麼實現分散式鎖之外,還需要考慮redis的部署問題。
redis有3種部署方式:
-
單機模式
-
master-slave + sentinel選舉模式
-
redis cluster模式
使用redis做分散式鎖的缺點在於:如果採用單機部署模式,會存在單點問題,只要redis故障了。加鎖就不行了。
採用master-slave模式,加鎖的時候只對一個節點加鎖,即便通過sentinel做了高可用,但是如果master節點故障了,發生主從切換,此時就會有可能出現鎖丟失的問題。
基於以上的考慮,其實redis的作者也考慮到這個問題,他提出了一個RedLock的演算法,這個演算法的意思大概是這樣的:
假設redis的部署模式是redis cluster,總共有5個master節點,通過以下步驟獲取一把鎖:
-
獲取當前時間戳,單位是毫秒
-
輪流嘗試在每個master節點上建立鎖,過期時間設定較短,一般就幾十毫秒
-
嘗試在大多數節點上建立一個鎖,比如5個節點就要求是3個節點(n / 2 +1)
-
客戶端計算建立好鎖的時間,如果建立鎖的時間小於超時時間,就算建立成功了
-
要是鎖建立失敗了,那麼就依次刪除這個鎖
-
只要別人建立了一把分散式鎖,你就得不斷輪詢去嘗試獲取鎖
但是這樣的這種演算法還是頗具爭議的,可能還會存在不少的問題,無法保證加鎖的過程一定正確。
另一種方式:Redisson
此外,實現Redis的分散式鎖,除了自己基於redis client原生api來實現之外,還可以使用開源框架:Redission
Redisson是一個企業級的開源Redis Client,也提供了分散式鎖的支援。我也非常推薦大家使用,為什麼呢?
回想一下上面說的,如果自己寫程式碼來通過redis設定一個值,是通過下面這個命令設定的。
-
SET anyLock unique_value NX PX 30000
這裡設定的超時時間是30s,假如我超過30s都還沒有完成業務邏輯的情況下,key會過期,其他執行緒有可能會獲取到鎖。
這樣一來的話,第一個執行緒還沒執行完業務邏輯,第二個執行緒進來了也會出現執行緒安全問題。所以我們還需要額外的去維護這個過期時間,太麻煩了~
我們來看看redisson是怎麼實現的?先感受一下使用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即可完成分散式鎖,他幫我們考慮了很多細節:
-
redisson所有指令都通過lua指令碼執行,redis支援lua指令碼原子性執行
-
redisson設定一個key的預設過期時間為30s,如果某個客戶端持有一個鎖超過了30s怎麼辦?
redisson中有一個
watchdog
的概念,翻譯過來就是看門狗,它會在你獲取鎖之後,每隔10秒幫你把key的超時時間設為30s這樣的話,就算一直持有鎖也不會出現key過期了,其他執行緒獲取到鎖的問題了。
-
redisson的“看門狗”邏輯保證了沒有死鎖發生。
(如果機器宕機了,看門狗也就沒了。此時就不會延長key的過期時間,到了30s之後就會自動過期了,其他執行緒可以獲取到鎖)
這裡稍微貼出來其實現程式碼:
// 加鎖邏輯 private <T> RFuture<Long> tryAcquireAsync(long leaseTime, TimeUnit unit, final long threadId) { if (leaseTime != -1) { return tryLockInnerAsync(leaseTime, unit, threadId, RedisCommands.EVAL_LONG); } // 呼叫一段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)); } // 看門狗最終會呼叫了這裡 private void scheduleExpirationRenewal(final long threadId) { if (expirationRenewalMap.containsKey(getEntryName())) { return; } // 這個任務會延遲10s執行 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 // 通過遞迴呼叫本方法,無限迴圈延長過期時間 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();
小結:
本節分析了使用redis作為分散式鎖的具體落地方案
以及其一些侷限性
然後介紹了一個redis的客戶端框架redisson,
這也是我推薦大家使用的,
比自己寫程式碼實現會少care很多細節。
基於zookeeper實現分散式鎖
常見的分散式鎖實現方案裡面,除了使用redis來實現之外,使用zookeeper也可以實現分散式鎖。
在介紹zookeeper(下文用zk代替)實現分散式鎖的機制之前,先粗略介紹一下zk是什麼東西:
Zookeeper是一種提供配置管理、分散式協同以及命名的中心化服務。
zk的模型是這樣的:zk包含一系列的節點,叫做znode,就好像檔案系統一樣每個znode表示一個目錄,然後znode有一些特性:
-
有序節點:假如當前有一個父節點為
/lock
,我們可以在這個父節點下面建立子節點;zookeeper提供了一個可選的有序特性,例如我們可以建立子節點“/lock/node-”並且指明有序,那麼zookeeper在生成子節點時會根據當前的子節點數量自動新增整數序號
也就是說,如果是第一個建立的子節點,那麼生成的子節點為
/lock/node-0000000000
,下一個節點則為/lock/node-0000000001
,依次類推。 -
臨時節點:客戶端可以建立一個臨時節點,在會話結束或者會話超時後,zookeeper會自動刪除該節點。
-
事件監聽:在讀取資料時,我們可以同時對節點設定事件監聽,當節點資料或結構變化時,zookeeper會通知客戶端。當前zookeeper有如下四種事件:
-
節點建立
-
節點刪除
-
節點資料修改
-
子節點變更
基於以上的一些zk的特性,我們很容易得出使用zk實現分散式鎖的落地方案:
-
使用zk的臨時節點和有序節點,每個執行緒獲取鎖就是在zk建立一個臨時有序的節點,比如在/lock/目錄下。
-
建立節點成功後,獲取/lock目錄下的所有臨時節點,再判斷當前執行緒建立的節點是否是所有的節點的序號最小的節點
-
如果當前執行緒建立的節點是所有節點序號最小的節點,則認為獲取鎖成功。
-
如果當前執行緒建立的節點不是所有節點序號最小的節點,則對節點序號的前一個節點新增一個事件監聽。
比如當前執行緒獲取到的節點序號為
/lock/003
,然後所有的節點列表為[/lock/001,/lock/002,/lock/003]
,則對/lock/002
這個節點新增一個事件監聽器。
如果鎖釋放了,會喚醒下一個序號的節點,然後重新執行第3步,判斷是否自己的節點序號是最小。
比如/lock/001
釋放了,/lock/002
監聽到時間,此時節點集合為[/lock/002,/lock/003]
,則/lock/002
為最小序號節點,獲取到鎖。
整個過程如下:
具體的實現思路就是這樣,至於程式碼怎麼寫,這裡比較複雜就不貼出來了。
Curator介紹
Curator是一個zookeeper的開源客戶端,也提供了分散式鎖的實現。
他的使用方式也比較簡單:
InterProcessMutex interProcessMutex = new InterProcessMutex(client,"/anyLock"); interProcessMutex.acquire(); interProcessMutex.release();
其實現分散式鎖的核心原始碼如下:
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 ) { // 獲取當前所有節點排序後的集合 List<String> children = getSortedChildren(); // 獲取當前節點的名稱 String sequenceNodeName = ourPath.substring(basePath.length() + 1); // +1 to include the slash // 判斷當前節點是否是最小的節點 PredicateResults predicateResults = driver.getsTheLock(client, children, sequenceNodeName, maxLeases); if ( predicateResults.getsTheLock() ) { // 獲取到鎖 haveTheLock = true; } else { // 沒獲取到鎖,對當前節點的上一個節點註冊一個監聽器 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實現分散式鎖的底層原理和上面分析的是差不多的。這裡我們用一張圖詳細描述其原理:
小結:
本節介紹了zookeeperr實現分散式鎖的方案以及zk的開源客戶端的基本使用,簡要的介紹了其實現原理。相關可以參考:肝一下ZooKeeper實現分散式鎖的方案,附帶例項!
兩種方案的優缺點比較
學完了兩種分散式鎖的實現方案之後,本節需要討論的是redis和zk的實現方案中各自的優缺點。
對於redis的分散式鎖而言,它有以下缺點:
-
它獲取鎖的方式簡單粗暴,獲取不到鎖直接不斷嘗試獲取鎖,比較消耗效能。
-
另外來說的話,redis的設計定位決定了它的資料並不是強一致性的,在某些極端情況下,可能會出現問題。鎖的模型不夠健壯
-
即便使用redlock演算法來實現,在某些複雜場景下,也無法保證其實現100%沒有問題,關於redlock的討論可以看How to do distributed locking
-
redis分散式鎖,其實需要自己不斷去嘗試獲取鎖,比較消耗效能。
但是另一方面使用redis實現分散式鎖在很多企業中非常常見,而且大部分情況下都不會遇到所謂的“極端複雜場景”
所以使用redis作為分散式鎖也不失為一種好的方案,最重要的一點是redis的效能很高,可以支撐高併發的獲取、釋放鎖操作。
對於zk分散式鎖而言:
-
zookeeper天生設計定位就是分散式協調,強一致性。鎖的模型健壯、簡單易用、適合做分散式鎖。
-
如果獲取不到鎖,只需要新增一個監聽器就可以了,不用一直輪詢,效能消耗較小。
但是zk也有其缺點:如果有較多的客戶端頻繁的申請加鎖、釋放鎖,對於zk叢集的壓力會比較大。
小結:
綜上所述,redis和zookeeper都有其優缺點。我們在做技術選型的時候可以根據這些問題作為參考因素。
建議
通過前面的分析,實現分散式鎖的兩種常見方案:redis和zookeeper,他們各有千秋。應該如何選型呢?
就個人而言的話,我比較推崇zk實現的鎖:
因為redis是有可能存在隱患的,可能會導致資料不對的情況。但是,怎麼選用要看具體在公司的場景了。
如果公司裡面有zk叢集條件,優先選用zk實現,但是如果說公司裡面只有redis叢集,沒有條件搭建zk叢集。
那麼其實用redis來實現也可以,另外還可能是系統設計者考慮到了系統已經有redis,但是又不希望再次引入一些外部依賴的情況下,可以選用redis。
這個是要系統設計者基於架構的考慮了