爲什麼用分佈式鎖？
在討論這個問題之前，我們先來看一個業務場景：
系統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 rLock = redisson.getLock("jaryle");//獲取到RLock，這個是redission最核心的鎖組件
try {
// boolean isLock = rLock.tryLock();
boolean isLock = rLock.tryLock(100, 1000, TimeUnit.SECONDS); //設置超時時間
if(isLock){
//TODO
}
}catch (Exception e){
e.printStackTrace();
}finally {
rLock.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分佈式鎖的實現我是基於組件提供的RLock.
RLock接口的特點
繼承標準接口Lock
擁有標準鎖接口的所有特性，比如lock,unlock,trylock等等。
擴展標準接口Lock
擴展了很多方法，常用的主要有：強制鎖釋放，帶有效期的鎖,還有一組異步的方法。其中前面兩個方法主要是解決標準lock可能造成的死鎖問題。比如某個線程獲取到鎖之後，線程所在機器死機，此時獲取了鎖的線程無法正常釋放鎖導致其餘的等待鎖的線程一直等待下去。
可重入機制
各版本實現有差異，可重入主要考慮的是性能，同一線程在未釋放鎖時如果再次申請鎖資源不需要走申請流程，只需要將已經獲取的鎖繼續返回並且記錄上已經重入的次數即可，與jdk裏面的ReentrantLock功能類似。重入次數靠hincrby命令來配合使用，詳細的參數下面的代碼。
怎麼判斷是同一線程？
redisson的方案是，RedissonLock實例的一個guid再加當前線程的id,通過getLockName返回public class RedissonLock extends RedissonExpirable implements RLock { final UUID id; protected RedissonLock(CommandExecutor commandExecutor, String name, UUID id) { super(commandExecutor, name); this.internalLockLeaseTime = TimeUnit.SECONDS.toMillis(30L); this.commandExecutor = commandExecutor; this.id = id; } String getLockName(long threadId) { return this.id + ":" + threadId; }
RLock獲取鎖的兩種場景
這裏拿tryLock的源碼來看：tryAcquire方法是申請鎖並返回鎖有效期還剩餘的時間，如果爲空說明鎖未被其它線程申請直接獲取並返回，如果獲取到時間，則進入等待競爭邏輯。
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
long time = unit.toMillis(waitTime);
long current = System.currentTimeMillis();
final long threadId = Thread.currentThread().getId();
Long ttl = this.tryAcquire(leaseTime, unit);
if(ttl == null) {
//直接獲取到鎖
return true;
} else {
//有競爭的後續看
}
}
無競爭，直接獲取鎖
先看下首先獲取鎖並釋放鎖背後的redis都在做什麼，可以利用redis的monitor來在後臺監控redis的執行情況。當我們在方法了增加@RequestLockable之後，其實就是調用lock以及unlock，下面是redis命令：
- 加鎖
由於高版本的redis支持lua腳本，所以redisson也對其進行了支持，採用了腳本模式，不熟悉lua腳本的可以去查找下。執行lua命令的邏輯如下：
<T> RFuture<T> tryLockInnerAsync(long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
this.internalLockLeaseTime = unit.toMillis(leaseTime);
return this.commandExecutor.evalWriteAsync(this.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.singletonList(this.getName()), new Object[]{Long.valueOf(this.internalLockLeaseTime), this.getLockName(threadId)});
}
加鎖的流程：
- 判斷lock鍵是否存在，不存在直接調用hset存儲當前線程信息並且設置過期時間,返回nil，告訴客戶端直接獲取到鎖。
- 判斷lock鍵是否存在，存在則將重入次數加1，並重新設置過期時間，返回nil，告訴客戶端直接獲取到鎖。
- 被其它線程已經鎖定，返回鎖有效期的剩餘時間，告訴客戶端需要等待。
"EVAL"
"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]);"
"1" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0"
"1000" "346e1eb8-5bfd-4d49-9870-042df402f248:21"
上面的lua腳本會轉換成真正的redis命令，下面的是經過lua腳本運算之後實際執行的redis命令。
1486642677.053488 [0 lua] "exists" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" 1486642677.053515 [0 lua] "hset" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" "346e1eb8-5bfd-4d49-9870-042df402f248:21" "1" 1486642677.053540 [0 lua] "pexpire" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0" "1000"
- 解鎖
解鎖的流程看起來複雜些：
- 如果lock鍵不存在，發消息說鎖已經可用
- 如果鎖不是被當前線程鎖定，則返回nil
- 由於支持可重入，在解鎖時將重入次數需要減1
- 如果計算後的重入次數>0，則重新設置過期時間
- 如果計算後的重入次數<=0，則發消息說鎖已經可用
"EVAL"
"if (redis.call('exists', KEYS[1]) == 0) then
redis.call('publish', KEYS[2], ARGV[1]);
return 1; end;
if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then
return nil;end;
local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1);
if (counter > 0) then redis.call('pexpire', KEYS[1], ARGV[2]); return 0;
else redis.call('del', KEYS[1]); redis.call('publish', KEYS[2], ARGV[1]); return 1; end;
return nil;"
"2" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0"
"redisson_lock__channel:{lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0}"
"0" "1000"
"346e1eb8-5bfd-4d49-9870-042df402f248:21"
無競爭情況下解鎖redis命令：
主要是發送一個解鎖的消息，以此喚醒等待隊列中的線程重新競爭鎖。
1486642678.493691 [0 lua] "exists" "lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0"
1486642678.493712 [0 lua] "publish" "redisson_lock__channel:{lock.com.csp.product.api.service.ProductAppService.searchProductByPage#0}" "0"
有競爭，等待
有競爭的情況在redis端的lua腳本是相同的，只是不同的條件執行不同的redis命令，複雜的在redisson的源碼上。當通過tryAcquire發現鎖被其它線程申請時，需要進入等待競爭邏輯中。
- this.await返回false，說明等待時間已經超出獲取鎖最大等待時間，取消訂閱並返回獲取鎖失敗
- this.await返回true，進入循環嘗試獲取鎖。
public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
long time = unit.toMillis(waitTime);
long current = System.currentTimeMillis();
final long threadId = Thread.currentThread().getId();
Long ttl = this.tryAcquire(leaseTime, unit);
if(ttl == null) {
return true;
} else {
//重點是這段
time -= System.currentTimeMillis() - current;
if(time <= 0L) {
return false;
} else {
current = System.currentTimeMillis();
final RFuture subscribeFuture = this.subscribe(threadId);
if(!this.await(subscribeFuture, time, TimeUnit.MILLISECONDS)) {
if(!subscribeFuture.cancel(false)) {
subscribeFuture.addListener(new FutureListener() {
public void operationComplete(Future<RedissonLockEntry> future) throws Exception {
if(subscribeFuture.isSuccess()) {
RedissonLock.this.unsubscribe(subscribeFuture, threadId);
}
}
});
}
return false;
} else {
boolean var16;
try {
time -= System.currentTimeMillis() - current;
if(time <= 0L) {
boolean currentTime1 = false;
return currentTime1;
}
do {
long currentTime = System.currentTimeMillis();
ttl = this.tryAcquire(leaseTime, unit);
if(ttl == null) {
var16 = true;
return var16;
}
time -= System.currentTimeMillis() - currentTime;
if(time <= 0L) {
var16 = false;
return var16;
}
currentTime = System.currentTimeMillis();
if(ttl.longValue() >= 0L && ttl.longValue() < time) {
this.getEntry(threadId).getLatch().tryAcquire(ttl.longValue(), TimeUnit.MILLISECONDS);
} else {
this.getEntry(threadId).getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
}
time -= System.currentTimeMillis() - currentTime;
} while(time > 0L);
var16 = false;
} finally {
this.unsubscribe(subscribeFuture, threadId);
}
return var16;
}
}
}
}
循環嘗試一般有如下幾種方法：
- while循環，一次接着一次的嘗試，這個方法的缺點是會造成大量無效的鎖申請。
- Thread.sleep，在上面的while方案中增加睡眠時間以降低鎖申請次數，缺點是這個睡眠的時間設置比較難控制。
- 基於信息量，當鎖被其它資源佔用時，當前線程訂閱鎖的釋放事件，一旦鎖釋放會發消息通知待等待的鎖進行競爭，有效的解決了無效的鎖申請情況。核心邏輯是this.getEntry(threadId).getLatch().tryAcquire，this.getEntry(threadId).getLatch()返回的是一個信號量，有興趣可以再研究研究。
另外，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。
這個是要系統設計者基於架構的考慮了。