分布式鎖用Redis好？還是Zookeeper好？

點(diǎn)擊上方“碼農(nóng)突圍”，馬上關(guān)注
這里是碼農(nóng)充電第一站，回復(fù)“666”，獲取一份專屬大禮包
真愛，請(qǐng)?jiān)O(shè)置“星標(biāo)”或點(diǎn)個(gè)“在看

來源：juejin.im/post/6891571079702118407

• Redis 實(shí)現(xiàn)
• 基于 Zookeeper 來實(shí)現(xiàn)分布式鎖
• 總結(jié)

---

不過目前互聯(lián)網(wǎng)項(xiàng)目越來越多的項(xiàng)目采用集群部署，也就是分布式情況，這兩種鎖就有些不夠用了。

來兩張圖舉例說明下，本地鎖的情況下：

分布式鎖情況下：

就其思想來說，就是一種“我全都要”的思想，所有服務(wù)都到一個(gè)統(tǒng)一的地方來取鎖，只有取到鎖的才能繼續(xù)執(zhí)行下去。

說完思想，下面來說一下具體的實(shí)現(xiàn)。

Redis 實(shí)現(xiàn)

為實(shí)現(xiàn)分布式鎖，在 Redis 中存在 SETNX key value 命令，意為 set if not exists（如果不存在該 key，才去 set 值），就比如說是張三去上廁所，看廁所門鎖著，他就不進(jìn)去了，廁所門開著他才去。

可以看到，第一次 set 返回了 1，表示成功，但是第二次返回 0，表示 set 失敗，因?yàn)橐呀?jīng)存在這個(gè) key 了。

當(dāng)然只靠 setnx 這個(gè)命令可以嗎？當(dāng)然是不行的，試想一種情況，張三在廁所里，但他在里面一直沒有釋放，一直在里面蹲著，那外面人想去廁所全部都去不了，都想錘死他了。

Redis 同理，假設(shè)已經(jīng)進(jìn)行了加鎖，但是因?yàn)殄礄C(jī)或者出現(xiàn)異常未釋放鎖，就造成了所謂的“死鎖”。

聰明的你們肯定早都想到了，為它設(shè)置過期時(shí)間不就好了，可以 SETEX key seconds value 命令，為指定 key 設(shè)置過期時(shí)間，單位為秒。

但這樣又有另一個(gè)問題，我剛加鎖成功，還沒設(shè)置過期時(shí)間，Redis 宕機(jī)了不就又死鎖了，所以說要保證原子性吖，要么一起成功，要么一起失敗。

當(dāng)然我們能想到的 Redis 肯定早都為你實(shí)現(xiàn)好了，在 Redis 2.8 的版本后，Redis 就為我們提供了一條組合命令 SET key value ex seconds nx，加鎖的同時(shí)設(shè)置過期時(shí)間。

就好比是公司規(guī)定每人最多只能在廁所呆 2 分鐘，不管釋放沒釋放完都得出來，這樣就解決了“死鎖”問題。

但這樣就沒有問題了嗎？怎么可能。

試想又一種情況，廁所門肯定只能從里面開啊，張三上完廁所后張四進(jìn)去鎖上門，但是外面人以為還是張三在里面，而且已經(jīng)過了 3 分鐘了，就直接把門給撬開了，一看里面卻是張四，這就很尷尬啊。

換成 Redis 就是說比如一個(gè)業(yè)務(wù)執(zhí)行時(shí)間很長(zhǎng)，鎖已經(jīng)自己過期了，別人已經(jīng)設(shè)置了新的鎖，但是當(dāng)業(yè)務(wù)執(zhí)行完之后直接釋放鎖，就有可能是刪除了別人加的鎖，這不是亂套了嗎。

所以在加鎖時(shí)候，要設(shè)一個(gè)隨機(jī)值，在刪除鎖時(shí)進(jìn)行比對(duì)，如果是自己的鎖，才刪除。

多說無益，煩人，直接上代碼：

//基于jedis和lua腳本來實(shí)現(xiàn)
privatestaticfinal?String?LOCK_SUCCESS?=?"OK";
privatestaticfinal?Long?RELEASE_SUCCESS?=?1L;
privatestaticfinal?String?SET_IF_NOT_EXIST?=?"NX";
privatestaticfinal?String?SET_WITH_EXPIRE_TIME?=?"PX";
?
@Override
public?String?acquire()?{
????try?{
????????//?獲取鎖的超時(shí)時(shí)間，超過這個(gè)時(shí)間則放棄獲取鎖
????????long?end?=?System.currentTimeMillis()?+?acquireTimeout;
????????//?隨機(jī)生成一個(gè)?value
????????String?requireToken?=?UUID.randomUUID().toString();
????????while?(System.currentTimeMillis()?????????????String?result?=?jedis
????????????????.set(lockKey,?requireToken,?SET_IF_NOT_EXIST,?SET_WITH_EXPIRE_TIME,?expireTime);
????????????if?(LOCK_SUCCESS.equals(result))?{
????????????????return?requireToken;
????????????}
????????????try?{
????????????????Thread.sleep(100);
????????????}?catch?(InterruptedException?e)?{
????????????????Thread.currentThread().interrupt();
????????????}
????????}
????}?catch?(Exception?e)?{
????????log.error("acquire?lock?due?to?error",?e);
????}
?
????returnnull;
}
?
@Override
public?boolean?release(String?identify)?{
????if?(identify?==?null)?{
????????returnfalse;
????}
????//通過lua腳本進(jìn)行比對(duì)刪除操作，保證原子性
????String?script?=?"if?redis.call('get',?KEYS[1])?==?ARGV[1]?then?return?redis.call('del',?KEYS[1])?else?return?0?end";
????Object?result?=?new?Object();
????try?{
????????result?=?jedis.eval(script,?Collections.singletonList(lockKey),
????????????Collections.singletonList(identify));
????????if?(RELEASE_SUCCESS.equals(result))?{
????????????log.info("release?lock?success,?requestToken:{}",?identify);
????????????returntrue;
????????}
????}?catch?(Exception?e)?{
????????log.error("release?lock?due?to?error",?e);
????}?finally?{
????????if?(jedis?!=?null)?{
????????????jedis.close();
????????}
????}
?
????log.info("release?lock?failed,?requestToken:{},?result:{}",?identify,?result);
????returnfalse;
}

思考：加鎖和釋放鎖的原子性可以用 lua 腳本來保證，那鎖的自動(dòng)續(xù)期改如何實(shí)現(xiàn)呢？

Redisson 實(shí)現(xiàn)

Redisson 顧名思義，Redis 的兒子，本質(zhì)上還是 Redis 加鎖，不過是對(duì) Redis 做了很多封裝，它不僅提供了一系列的分布式的 Java 常用對(duì)象，還提供了許多分布式服務(wù)。

在引入 Redisson 的依賴后，就可以直接進(jìn)行調(diào)用：

????org.redisson
????redisson
????3.13.4

先來一段 Redisson 的加鎖代碼：

private?void?test()?{
????//分布式鎖名??鎖的粒度越細(xì)，性能越好
????RLock?lock?=?redissonClient.getLock("test_lock");
????lock.lock();
????try?{
????????//具體業(yè)務(wù)......
????}?finally?{
????????lock.unlock();
????}
}

就是這么簡(jiǎn)單，使用方法 jdk 的 ReentrantLock 差不多，并且也支持 ReadWriteLock（讀寫鎖）、Reentrant Lock（可重入鎖）、Fair Lock（公平鎖）、RedLock（紅鎖）等各種鎖，詳細(xì)可以參照redisson官方文檔來查看。

那么 Redisson 到底有哪些優(yōu)勢(shì)呢？鎖的自動(dòng)續(xù)期（默認(rèn)都是 30 秒），如果業(yè)務(wù)超長(zhǎng)，運(yùn)行期間會(huì)自動(dòng)給鎖續(xù)上新的 30s，不用擔(dān)心業(yè)務(wù)執(zhí)行時(shí)間超長(zhǎng)而鎖被自動(dòng)刪掉。

加鎖的業(yè)務(wù)只要運(yùn)行完成，就不會(huì)給當(dāng)前續(xù)期，即便不手動(dòng)解鎖，鎖默認(rèn)在 30s 后刪除，不會(huì)造成死鎖問題。

前面也提到了鎖的自動(dòng)續(xù)期，我們來看看 Redisson 是如何來實(shí)現(xiàn)的。

先說明一下，這里主要講的是 Redisson 中的 RLock，也就是可重入鎖，有兩種實(shí)現(xiàn)方法：

//?最常見的使用方法
lock.lock();
?
//?加鎖以后10秒鐘自動(dòng)解鎖
//?無需調(diào)用unlock方法手動(dòng)解鎖
lock.lock(10,?TimeUnit.SECONDS);

而只有無參的方法是提供鎖的自動(dòng)續(xù)期操作的，內(nèi)部使用的是“看門狗”機(jī)制，我們來看一看源碼。

不管是空參還是帶參方法，它們都調(diào)用的是同一個(gè) lock 方法，未傳參的話時(shí)間傳了一個(gè) -1，而帶參的方法傳過去的就是實(shí)際傳入的時(shí)間。

繼續(xù)點(diǎn)進(jìn) scheduleExpirationRenewal 方法：

點(diǎn)進(jìn) renewExpiration 方法：

總結(jié)一下，就是當(dāng)我們指定鎖過期時(shí)間，那么鎖到時(shí)間就會(huì)自動(dòng)釋放。如果沒有指定鎖過期時(shí)間，就使用看門狗的默認(rèn)時(shí)間 30s，只要占鎖成功，就會(huì)啟動(dòng)一個(gè)定時(shí)任務(wù)，每隔 10s 給鎖設(shè)置新的過期時(shí)間，時(shí)間為看門狗的默認(rèn)時(shí)間，直到鎖釋放。

小結(jié)：雖然 lock() 有自動(dòng)續(xù)鎖機(jī)制，但是開發(fā)中還是推薦使用 lock(time，timeUnit)，因?yàn)樗〉袅苏麄€(gè)續(xù)期帶來的性能損，可以設(shè)置過期時(shí)間長(zhǎng)一點(diǎn)，搭配 unlock()。

若業(yè)務(wù)執(zhí)行完成，會(huì)手動(dòng)釋放鎖，若是業(yè)務(wù)執(zhí)行超時(shí)，那一般我們服務(wù)也都會(huì)設(shè)置業(yè)務(wù)超時(shí)時(shí)間，就直接報(bào)錯(cuò)了，報(bào)錯(cuò)后就會(huì)通過設(shè)置的過期時(shí)間來釋放鎖。

public?void?test()?{
????RLock?lock?=?redissonClient.getLock("test_lock");
????lock.lock(30,?TimeUnit.SECONDS);
????try?{
????????//.......具體業(yè)務(wù)
????}?finally?{
????????//手動(dòng)釋放鎖
????????lock.unlock();
????}
}

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

很多小伙伴都知道在分布式系統(tǒng)中，可以用 ZK 來做注冊(cè)中心，但其實(shí)在除了做祖冊(cè)中心以外，用 ZK 來做分布式鎖也是很常見的一種方案。

先來看一下 ZK 中是如何創(chuàng)建一個(gè)節(jié)點(diǎn)的？ZK 中存在 create [-s] [-e] path [data] 命令，-s 為創(chuàng)建有序節(jié)點(diǎn)，-e 創(chuàng)建臨時(shí)節(jié)點(diǎn)。

這樣就創(chuàng)建了一個(gè)父節(jié)點(diǎn)并為父節(jié)點(diǎn)創(chuàng)建了一個(gè)子節(jié)點(diǎn)，組合命令意為創(chuàng)建一個(gè)臨時(shí)的有序節(jié)點(diǎn)。

而 ZK 中分布式鎖主要就是靠創(chuàng)建臨時(shí)的順序節(jié)點(diǎn)來實(shí)現(xiàn)的。至于為什么要用順序節(jié)點(diǎn)和為什么用臨時(shí)節(jié)點(diǎn)不用持久節(jié)點(diǎn)？先考慮一下，下文將作出說明。

同時(shí)還有 ZK 中如何查看節(jié)點(diǎn)？ZK 中 ls [-w] path 為查看節(jié)點(diǎn)命令，-w 為添加一個(gè) watch（監(jiān)視器），/ 為查看根節(jié)點(diǎn)所有節(jié)點(diǎn)，可以看到我們剛才所創(chuàng)建的節(jié)點(diǎn)，同時(shí)如果是跟著指定節(jié)點(diǎn)名字的話為查看指定節(jié)點(diǎn)下的子節(jié)點(diǎn)。

后面的 00000000 為 ZK 為順序節(jié)點(diǎn)增加的順序。注冊(cè)監(jiān)聽器也是 ZK 實(shí)現(xiàn)分布式鎖中比較重要的一個(gè)東西。

下面來看一下 ZK 實(shí)現(xiàn)分布式鎖的主要流程：

• 當(dāng)?shù)谝粋€(gè)線程進(jìn)來時(shí)會(huì)去父節(jié)點(diǎn)上創(chuàng)建一個(gè)臨時(shí)的順序節(jié)點(diǎn)。
• 第二個(gè)線程進(jìn)來發(fā)現(xiàn)鎖已經(jīng)被持有了，就會(huì)為當(dāng)前持有鎖的節(jié)點(diǎn)注冊(cè)一個(gè) watcher 監(jiān)聽器。
• 第三個(gè)線程進(jìn)來發(fā)現(xiàn)鎖已經(jīng)被持有了，因?yàn)槭琼樞蚬?jié)點(diǎn)的緣故，就會(huì)為上一個(gè)節(jié)點(diǎn)去創(chuàng)建一個(gè) watcher 監(jiān)聽器。
• 當(dāng)?shù)谝粋€(gè)線程釋放鎖后，刪除節(jié)點(diǎn)，由它的下一個(gè)節(jié)點(diǎn)去占有鎖。

看到這里，聰明的小伙伴們都已經(jīng)看出來順序節(jié)點(diǎn)的好處了。非順序節(jié)點(diǎn)的話，每進(jìn)來一個(gè)線程進(jìn)來都會(huì)去持有鎖的節(jié)點(diǎn)上注冊(cè)一個(gè)監(jiān)聽器，容易引發(fā)“羊群效應(yīng)”。

這么大一群羊一起向你飛奔而來，不管你頂不頂?shù)米?，反?ZK 服務(wù)器是會(huì)增大宕機(jī)的風(fēng)險(xiǎn)。

而順序節(jié)點(diǎn)的話就不會(huì)，順序節(jié)點(diǎn)當(dāng)發(fā)現(xiàn)已經(jīng)有線程持有鎖后，會(huì)向它的上一個(gè)節(jié)點(diǎn)注冊(cè)一個(gè)監(jiān)聽器，這樣當(dāng)持有鎖的節(jié)點(diǎn)釋放后，也只有持有鎖的下一個(gè)節(jié)點(diǎn)可以搶到鎖，相當(dāng)于是排好隊(duì)來執(zhí)行的，降低服務(wù)器宕機(jī)風(fēng)險(xiǎn)。

至于為什么使用臨時(shí)節(jié)點(diǎn)，和 Redis 的過期時(shí)間一個(gè)道理，就算 ZK 服務(wù)器宕機(jī)，臨時(shí)節(jié)點(diǎn)會(huì)隨著服務(wù)器的宕機(jī)而消失，避免了死鎖的情況。

下面來上一段代碼的實(shí)現(xiàn)：

public?class?ZooKeeperDistributedLock?implements?Watcher?{
?
????private?ZooKeeper?zk;
????private?String?locksRoot?=?"/locks";
????private?String?productId;
????private?String?waitNode;
????private?String?lockNode;
????private?CountDownLatch?latch;
????private?CountDownLatch?connectedLatch?=?new?CountDownLatch(1);
????private?int?sessionTimeout?=?30000;
?
????public?ZooKeeperDistributedLock(String?productId)?{
????????this.productId?=?productId;
????????try?{
????????????String?address?=?"192.168.189.131:2181,192.168.189.132:2181";
????????????zk?=?new?ZooKeeper(address,?sessionTimeout,?this);
????????????connectedLatch.await();
????????}?catch?(IOException?e)?{
????????????throw?new?LockException(e);
????????}?catch?(KeeperException?e)?{
????????????throw?new?LockException(e);
????????}?catch?(InterruptedException?e)?{
????????????throw?new?LockException(e);
????????}
????}
?
????public?void?process(WatchedEvent?event)?{
????????if?(event.getState()?==?KeeperState.SyncConnected)?{
????????????connectedLatch.countDown();
????????????return;
????????}
?
????????if?(this.latch?!=?null)?{
????????????this.latch.countDown();
????????}
????}
?
????public?void?acquireDistributedLock()?{
????????try?{
????????????if?(this.tryLock())?{
????????????????return;
????????????}?else?{
????????????????waitForLock(waitNode,?sessionTimeout);
????????????}
????????}?catch?(KeeperException?e)?{
????????????throw?new?LockException(e);
????????}?catch?(InterruptedException?e)?{
????????????throw?new?LockException(e);
????????}
????}
????//獲取鎖
????public?boolean?tryLock()?{
????????try?{
????????//?傳入進(jìn)去的locksRoot?+?“/”?+?productId
????????//?假設(shè)productId代表了一個(gè)商品id，比如說1
????????//?locksRoot?=?locks
????????//?/locks/10000000000，/locks/10000000001，/locks/10000000002
????????lockNode?=?zk.create(locksRoot?+?"/"?+?productId,?new?byte[0],?ZooDefs.Ids.OPEN_ACL_UNSAFE,?CreateMode.EPHEMERAL_SEQUENTIAL);
?
????????//?看看剛創(chuàng)建的節(jié)點(diǎn)是不是最小的節(jié)點(diǎn)
????????// locks：10000000000，10000000001，10000000002
????????List?locks?=?zk.getChildren(locksRoot,?false);
????????Collections.sort(locks);
?
????????if(lockNode.equals(locksRoot+"/"+?locks.get(0))){
????????????//如果是最小的節(jié)點(diǎn),則表示取得鎖
????????????return?true;
????????}
?
????????//如果不是最小的節(jié)點(diǎn)，找到比自己小1的節(jié)點(diǎn)
??????int?previousLockIndex?=?-1;
????????????for(int?i?=?0;?i?????????if(lockNode.equals(locksRoot?+?“/”?+?locks.get(i)))?{
????????????????????previousLockIndex?=?i?-?1;
????????????break;
????????}
???????}
?
???????this.waitNode?=?locks.get(previousLockIndex);
????????}?catch?(KeeperException?e)?{
????????????throw?new?LockException(e);
????????}?catch?(InterruptedException?e)?{
????????????throw?new?LockException(e);
????????}
????????return?false;
????}
?
????private?boolean?waitForLock(String?waitNode,?long?waitTime)?throws?InterruptedException,?KeeperException?{
????????Stat?stat?=?zk.exists(locksRoot?+?"/"?+?waitNode,?true);
????????if?(stat?!=?null)?{
????????????this.latch?=?new?CountDownLatch(1);
????????????this.latch.await(waitTime,?TimeUnit.MILLISECONDS);
????????????this.latch?=?null;
????????}
????????return?true;
????}
?
????//釋放鎖
????public?void?unlock()?{
????????try?{
????????????System.out.println("unlock?"?+?lockNode);
????????????zk.delete(lockNode,?-1);
????????????lockNode?=?null;
????????????zk.close();
????????}?catch?(InterruptedException?e)?{
????????????e.printStackTrace();
????????}?catch?(KeeperException?e)?{
????????????e.printStackTrace();
????????}
????}
????//異常
????public?class?LockException?extends?RuntimeException?{
????????private?static?final?long?serialVersionUID?=?1L;
?
????????public?LockException(String?e)?{
????????????super(e);
????????}
?
????????public?LockException(Exception?e)?{
????????????super(e);
????????}
????}
}

總結(jié)

既然明白了 Redis 和 ZK 分別對(duì)分布式鎖的實(shí)現(xiàn)，那么總該有所不同的吧。沒錯(cuò)，我都幫大家整理好了：

• 實(shí)現(xiàn)方式的不同，Redis 實(shí)現(xiàn)為去插入一條占位數(shù)據(jù)，而 ZK 實(shí)現(xiàn)為去注冊(cè)一個(gè)臨時(shí)節(jié)點(diǎn)。
• 遇到宕機(jī)情況時(shí)，Redis 需要等到過期時(shí)間到了后自動(dòng)釋放鎖，而 ZK 因?yàn)槭桥R時(shí)節(jié)點(diǎn)，在宕機(jī)時(shí)候已經(jīng)是刪除了節(jié)點(diǎn)去釋放鎖。
• Redis 在沒搶占到鎖的情況下一般會(huì)去自旋獲取鎖，比較浪費(fèi)性能，而 ZK 是通過注冊(cè)監(jiān)聽器的方式獲取鎖，性能而言優(yōu)于 Redis。

不過具體要采用哪種實(shí)現(xiàn)方式，還是需要具體情況具體分析，結(jié)合項(xiàng)目引用的技術(shù)棧來落地實(shí)現(xiàn)。

-End-
最近有一些小伙伴，讓我?guī)兔φ乙恍?面試題?資料，于是我翻遍了收藏的 5T 資料后，匯總整理出來，可以說是程序員面試必備！所有資料都整理到網(wǎng)盤了，歡迎下載！

點(diǎn)擊??卡片，關(guān)注后回復(fù)【面試題】即可獲取