雲栖号資訊：【 點選檢視更多行業資訊】
在這裡您可以找到不同行業的第一手的上雲資訊，還在等什麼，快來！
為什麼用分布式鎖？
在讨論這個問題之前，我們先來看一個業務場景：
系統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删除。
具體代碼是這樣的：
這種方式有幾大要點：
-
一定要用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節點故障了，發生主從切換，此時就會有可能出現鎖丢失的問題。”關注微信公衆号：網際網路架構師，在背景回複：2T，可以擷取我整理的教程，都是幹貨。
基于以上的考慮，其實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的爽：
就是這麼簡單，我們隻需要通過它的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的開源用戶端的基本使用，簡要的介紹了其實作原理。
兩種方案的優缺點比較
學完了兩種分布式鎖的實作方案之後，本節需要讨論的是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。
這個是要系統設計者基于架構的考慮了
【雲栖号線上課堂】每天都有産品技術專家分享！
課程位址：
https://yqh.aliyun.com/zhibo立即加入社群，與專家面對面，及時了解課程最新動态！
【雲栖号線上課堂 社群】
https://c.tb.cn/F3.Z8gvnK
原文釋出時間：2020-07-01
本文作者：網際網路架構師
本文來自：“
網際網路架構師 微信公衆号”，了解相關資訊可以關注“[網際網路架構師](
https://mp.weixin.qq.com/s/0sl7lYsLFgiuYC-0S5BSJA）