Zookeeper和Redis實現(xiàn)分布式鎖，附我的可靠性分析

時間：2021-08-13 17:04:09

關(guān)鍵字： Zookeeper Redis 分布式鎖

手機看文章

掃描二維碼
隨時隨地手機看文章

[導(dǎo)讀]在分布式系統(tǒng)中，為保證同一時間只有一個客戶端可以對共享資源進(jìn)行操作，需要對共享資源加鎖來實現(xiàn)，常見有三種方式：基于數(shù)據(jù)庫實現(xiàn)分布式鎖基于Redis實現(xiàn)分布式鎖基于Zookeeper實現(xiàn)分布式鎖高并發(fā)下數(shù)據(jù)庫鎖性能太差，本文不做探究。僅針對Redis和Zookeeper實現(xiàn)的分布式...

在分布式系統(tǒng)中，為保證同一時間只有一個客戶端可以對共享資源進(jìn)行操作，需要對共享資源加鎖來實現(xiàn)，常見有三種方式：

基于數(shù)據(jù)庫實現(xiàn)分布式鎖
基于 Redis 實現(xiàn)分布式鎖
基于 Zookeeper 實現(xiàn)分布式鎖

高并發(fā)下數(shù)據(jù)庫鎖性能太差，本文不做探究。僅針對Redis 和 Zookeeper 實現(xiàn)的分布式鎖進(jìn)行分析。
實現(xiàn)一個分布式鎖應(yīng)該具備的特性：

高可用、高性能的獲取鎖與釋放鎖
在分布式系統(tǒng)環(huán)境下，一個方法或者變量同一時間只能被一個線程操作
具備鎖失效機制，網(wǎng)絡(luò)中斷或宕機無法釋放鎖時，鎖必須被刪除，防止死鎖
具備阻塞鎖特性，即沒有獲取到鎖，則繼續(xù)等待獲取鎖
具備非阻塞鎖特性，即沒有獲取到鎖，則直接返回獲取鎖失敗
具備可重入特性，一個線程中可以多次獲取同一把鎖，比如一個線程在執(zhí)行一個帶鎖的方法，該方法中又調(diào)用了另一個需要相同鎖的方法，則該線程可以直接執(zhí)行調(diào)用的方法，而無需重新獲得鎖

先上結(jié)論，Redis在鎖時間限制和緩存一致性存在一定問題，Zookeeper在可靠性上強于Redis，只是效率相對較低，開發(fā)人員需要根據(jù)實際需求進(jìn)行技術(shù)選型。
單機情況下：

1. Redis單機實現(xiàn)分布式鎖

1.1 Redis加鎖
//SET resource_name my_random_value NX PX 30000
String result = jedis.set(key, value, "NX", "PX", 30000);
if ("OK".equals(result)) {
return true; //代表獲取到鎖
}
return false;
加鎖就一行代碼：jedis.set(String key, String value, String nxxx, String expx, int time)，這個set()方法一共有五個形參：

第一個為key，使用key來當(dāng)鎖，因為key是唯一的。
第二個為value，是由客戶端生成的一個隨機字符串，相當(dāng)于是客戶端持有鎖的標(biāo)志。用于標(biāo)識加鎖和解鎖必須是同一個客戶端。
第三個為nxxx，傳的是NX，意思是SET IF NOT EXIST，即當(dāng)key不存在時，進(jìn)行set操作；若key已經(jīng)存在，則不做任何操作。
第四個為expx，傳的是PX，意思是我們要給這個key加一個過期的設(shè)置，具體時間由第五個參數(shù)決定。
第五個為time，與第四個參數(shù)相呼應(yīng)，代表key的過期時間，如上30000表示這個鎖有一個30秒的自動過期時間。

1.2 Redis解鎖
解鎖時，為了防止客戶端1獲得的鎖，被客戶端2給釋放，需要采用的Lua腳本來釋放鎖：
final Long RELEASE_SUCCESS = 1L;
//采用Lua腳本來釋放鎖
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));
if (RELEASE_SUCCESS.equals(result)) {
return true;
}
return false;
在執(zhí)行這段Lua腳本的時候，KEYS[1]的值為 key，ARGV[1]的值為 value。原理就是先獲取鎖對應(yīng)的value值，保證和客戶端傳進(jìn)去的value值相等，這樣就能避免自己的鎖被其他人釋放。另外，采取Lua腳本操作保證了原子性。如果不是原子性操作，則有了下述情況出現(xiàn)：
Zookeeper和Redis實現(xiàn)分布式鎖，附我的可靠性分析

1.3 Redis加鎖過期時間設(shè)置問題
理想情況是客戶端Redis加鎖后，完成一系列業(yè)務(wù)操作，順利在鎖過期時間前釋放掉鎖，這個分布式鎖的設(shè)置是有效的。但是如果客戶端在操作共享資源的過程中，因為長期阻塞的原因，導(dǎo)致鎖過期，那么接下來訪問共享資源就變得不再安全。

2. Zookeeper單機實現(xiàn)分布式鎖

2.1 Curator實現(xiàn)Zookeeper加解鎖
使用 Apache 開源的curator 可實現(xiàn) Zookeeper 分布式鎖。
可以通過調(diào)用 InterProcessLock接口提供的幾個方法來實現(xiàn)加鎖、解鎖。
/**
* 獲取鎖、阻塞等待、可重入
*/
public void acquire() throws Exception;
/**
* 獲取鎖、阻塞等待、可重入、超時則獲取失敗
*/
public boolean acquire(long time, TimeUnit unit) throws Exception;
/**
* 釋放鎖
*/
public void release() throws Exception;
/**
* Returns true if the mutex is acquired by a thread in this JVM
*/
boolean isAcquiredInThisProcess();
2.2 Zookeeper加鎖實現(xiàn)原理
Zookeeper的分布式鎖原理是利用了臨時節(jié)點(EPHEMERAL)的特性。其實現(xiàn)原理：

創(chuàng)建一個鎖目錄lock
線程A獲取鎖會在lock目錄下，創(chuàng)建臨時順序節(jié)點
獲取鎖目錄下所有的子節(jié)點，然后獲取比自己小的兄弟節(jié)點，如果不存在，則說明當(dāng)前線程順序號最小，獲得鎖
線程B創(chuàng)建臨時節(jié)點并獲取所有兄弟節(jié)點，判斷自己不是最小節(jié)點，設(shè)置監(jiān)聽(watcher)比自己次小的節(jié)點（只關(guān)注比自己次小的節(jié)點是為了防止發(fā)生“羊群效應(yīng)”）
線程A處理完，刪除自己的節(jié)點，線程B監(jiān)聽到變更事件，判斷自己是最小的節(jié)點，獲得鎖

由于節(jié)點的臨時屬性，如果創(chuàng)建znode的那個客戶端崩潰了，那么相應(yīng)的znode會被自動刪除。這樣就避免了設(shè)置過期時間的問題。
2.3 GC停頓導(dǎo)致臨時節(jié)點釋放問題
但是使用臨時節(jié)點又會存在另一個問題：Zookeeper如果長時間檢測不到客戶端的心跳的時候(Session時間)，就會認(rèn)為Session過期了，那么這個Session所創(chuàng)建的所有的ephemeral類型的znode節(jié)點都會被自動刪除。
Zookeeper和Redis實現(xiàn)分布式鎖，附我的可靠性分析

如上圖所示，客戶端1發(fā)生GC停頓的時候，Zookeeper檢測不到心跳，也是有可能出現(xiàn)多個客戶端同時操作共享資源的情形。當(dāng)然，你可以說，我們可以通過JVM調(diào)優(yōu)，避免GC停頓出現(xiàn)。但是注意了，我們所做的一切，只能盡可能避免多個客戶端操作共享資源，無法完全消除。
集群情況下：

3. Redis集群下分布式鎖存在問題

3.1 集群Master宕機導(dǎo)致鎖丟失
為了Redis的高可用，一般都會給Redis的節(jié)點掛一個slave,然后采用哨兵模式進(jìn)行主備切換。但由于Redis的主從復(fù)制（replication）是異步的，這可能會出現(xiàn)在數(shù)據(jù)同步過程中，master宕機，slave來不及同步數(shù)據(jù)就被選為master，從而數(shù)據(jù)丟失。具體流程如下所示：

(1)客戶端1從Master獲取了鎖。
(2)Master宕機了，存儲鎖的key還沒有來得及同步到Slave上。
(3)Slave升級為Master。
(4)客戶端1的鎖丟失，客戶端2從新的Master獲取到了對應(yīng)同一個資源的鎖。

3.2 Redlock算法
為了應(yīng)對這個情形， Redis作者antirez基于分布式環(huán)境下提出了一種更高級的分布式鎖的實現(xiàn)方式：Redlock。
antirez提出的redlock算法大概是這樣的：
在Redis的分布式環(huán)境中，我們假設(shè)有N個Redis master。這些節(jié)點完全互相獨立，不存在主從復(fù)制或者其他集群協(xié)調(diào)機制。我們確保將在N個實例上使用與在Redis單實例下相同方法獲取和釋放鎖?，F(xiàn)在我們假設(shè)有5個Redis master節(jié)點(官方文檔里將N設(shè)置成5，其實大等于3就行)，同時我們需要在5臺服務(wù)器上面運行這些Redis實例，這樣保證他們不會同時都宕掉。
為了取到鎖，客戶端應(yīng)該執(zhí)行以下操作:

(1)獲取當(dāng)前Unix時間，以毫秒為單位。
(2)依次嘗試從5個實例，使用相同的key和具有唯一性的value（例如UUID）獲取鎖。當(dāng)向Redis請求獲取鎖時，客戶端應(yīng)該設(shè)置一個網(wǎng)絡(luò)連接和響應(yīng)超時時間，這個超時時間應(yīng)該小于鎖的失效時間。例如你的鎖自動失效時間為10秒，則超時時間應(yīng)該在5-50毫秒之間。這樣可以避免服務(wù)器端Redis已經(jīng)掛掉的情況下，客戶端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒有在規(guī)定時間內(nèi)響應(yīng)，客戶端應(yīng)該盡快嘗試去另外一個Redis實例請求獲取鎖。
(3)客戶端使用當(dāng)前時間減去開始獲取鎖時間（步驟1記錄的時間）就得到獲取鎖使用的時間。當(dāng)且僅當(dāng)從大多數(shù)（N/2 1，這里是3個節(jié)點）的Redis節(jié)點都取到鎖，并且使用的時間小于鎖失效時間時，鎖才算獲取成功。
(4)如果取到了鎖，key的真正有效時間等于有效時間減去獲取鎖所使用的時間（步驟3計算的結(jié)果）。
(5)如果因為某些原因，獲取鎖失敗（沒有在至少N/2 1個Redis實例取到鎖或者取鎖時間已經(jīng)超過了有效時間），客戶端應(yīng)該在所有的Redis實例上進(jìn)行解鎖（即便某些Redis實例根本就沒有加鎖成功，防止某些節(jié)點獲取到鎖但是客戶端沒有得到響應(yīng)而導(dǎo)致接下來的一段時間不能被重新獲取鎖）。

redisson已經(jīng)有對redlock算法封裝，如下是調(diào)用代碼示例：
Config config = new Config();
config.useSentinelServers().addSentinelAddress("127.0.0.1:6369","127.0.0.1:6379", "127.0.0.1:6389")
.setMasterName("masterName")
.setPassword("password").setDatabase(0);
RedissonClient redissonClient = Redisson.create(config);
// 還可以getFairLock(), getReadWriteLock()
RLock redLock = redissonClient.getLock("REDLOCK_KEY");
boolean isLock;
try {
isLock = redLock.tryLock();
// 500ms拿不到鎖, 就認(rèn)為獲取鎖失敗。10000ms即10s是鎖失效時間。
isLock = redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS);
if (isLock) {
//TODO if get lock success, do something;
}
} catch (Exception e) {
} finally {
// 無論如何, 最后都要解鎖
redLock.unlock();
}
3.3 Redlock未完全解決問題
Redlock算法細(xì)想一下還存在下面的問題：節(jié)點崩潰重啟，會出現(xiàn)多個客戶端持有鎖 假設(shè)一共有5個Redis節(jié)點：A, B, C, D, E。設(shè)想發(fā)生了如下的事件序列：

(1)客戶端1成功鎖住了A, B, C，獲取鎖成功（但D和E沒有鎖住）。
(2)節(jié)點C崩潰重啟了，但客戶端1在C上加的鎖沒有持久化下來，丟失了。
(3)節(jié)點C重啟后，客戶端2鎖住了C, D, E，獲取鎖成功。

這樣，客戶端1和客戶端2同時獲得了鎖（針對同一資源）。
為了應(yīng)對節(jié)點重啟引發(fā)的鎖失效問題，redis的作者antirez提出了延遲重啟的概念，即一個節(jié)點崩潰后，先不立即重啟它，而是等待一段時間再重啟，等待的時間大于鎖的有效時間。采用這種方式，這個節(jié)點在重啟前所參與的鎖都會過期，它在重啟后就不會對現(xiàn)有的鎖造成影響。這其實也是通過人為補償措施，降低不一致發(fā)生的概率。時間跳躍問題

(1)假設(shè)一共有5個Redis節(jié)點：A, B, C, D, E。設(shè)想發(fā)生了如下的事件序列：
(2)客戶端1從Redis節(jié)點A, B, C成功獲取了鎖（多數(shù)節(jié)點）。由于網(wǎng)絡(luò)問題，與D和E通信失敗。
(3)節(jié)點C上的時鐘發(fā)生了向前跳躍，導(dǎo)致它上面維護(hù)的鎖快速過期。
(4)客戶端2從Redis節(jié)點C, D, E成功獲取了同一個資源的鎖（多數(shù)節(jié)點）。
(5)客戶端1和客戶端2現(xiàn)在都認(rèn)為自己持有了鎖。

為了應(yīng)對始終跳躍引發(fā)的鎖失效問題，redis的作者antirez提出了應(yīng)該禁止人為修改系統(tǒng)時間，使用一個不會進(jìn)行“跳躍”式調(diào)整系統(tǒng)時鐘的ntpd程序。這也是通過人為補償措施，降低不一致發(fā)生的概率。超時導(dǎo)致鎖失效問題 RedLock算法并沒有解決，操作共享資源超時，導(dǎo)致鎖失效的問題。回憶一下RedLock算法的過程，如下圖所示
Zookeeper和Redis實現(xiàn)分布式鎖，附我的可靠性分析

如圖所示，我們將其分為上下兩個部分。對于上半部分框圖里的步驟來說，無論因為什么原因發(fā)生了延遲，RedLock算法都能處理，客戶端不會拿到一個它認(rèn)為有效，實際卻失效的鎖。然而，對于下半部分框圖里的步驟來說，如果發(fā)生了延遲導(dǎo)致鎖失效，都有可能使得客戶端2拿到鎖。因此，RedLock算法并沒有解決該問題。

4. Zookeeper集群下分布式鎖可靠性分析

4.1 Zookeeper的寫數(shù)據(jù)的原理
Zookeeper在集群部署中，Zookeeper節(jié)點數(shù)量一般是奇數(shù)，且一定大等于3。下面是Zookeeper的寫數(shù)據(jù)的原理：
Zookeeper和Redis實現(xiàn)分布式鎖，附我的可靠性分析

那么寫數(shù)據(jù)流程步驟如下：

(1)在Client向Follwer發(fā)出一個寫的請求
(2)Follwer把請求發(fā)送給Leader
(3)Leader接收到以后開始發(fā)起投票并通知Follwer進(jìn)行投票
(4)Follwer把投票結(jié)果發(fā)送給Leader，只要半數(shù)以上返回了ACK信息，就認(rèn)為通過
(5)Leader將結(jié)果匯總后如果需要寫入，則開始寫入同時把寫入操作通知給Leader，然后commit;
(6)Follwer把請求結(jié)果返回給Client

還有一點，Zookeeper采取的是全局串行化操作。
4.2 集群模式下Zookeeper可靠性分析
下面列出Redis集群下分布式鎖可能存在的問題，判斷其在Zookeeper集群下是否會存在：
集群同步

client給Follwer寫數(shù)據(jù)，可是Follwer卻宕機了，會出現(xiàn)數(shù)據(jù)不一致問題么？不可能，這種時候，client建立節(jié)點失敗，根本獲取不到鎖。
client給Follwer寫數(shù)據(jù)，F(xiàn)ollwer將請求轉(zhuǎn)發(fā)給Leader，Leader宕機了，會出現(xiàn)不一致的問題么？不可能，這種時候，Zookeeper會選取新的leader，繼續(xù)上面的提到的寫流程。

總之，采用Zookeeper作為分布式鎖，你要么就獲取不到鎖，一旦獲取到了，必定節(jié)點的數(shù)據(jù)是一致的，不會出現(xiàn)redis那種異步同步導(dǎo)致數(shù)據(jù)丟失的問題。時間跳躍問題 Zookeeper不依賴全局時間，不存在該問題。超時導(dǎo)致鎖失效問題 Zookeeper不依賴有效時間，不存在該問題。

5. 鎖的其他特性比較

redis的讀寫性能比Zookeeper強太多，如果在高并發(fā)場景中，使用Zookeeper作為分布式鎖，那么會出現(xiàn)獲取鎖失敗的情況，存在性能瓶頸。
Zookeeper可以實現(xiàn)讀寫鎖，Redis不行。
Zookeeper的watch機制,客戶端試圖創(chuàng)建znode的時候，發(fā)現(xiàn)它已經(jīng)存在了，這時候創(chuàng)建失敗,那么進(jìn)入一種等待狀態(tài)，當(dāng)znode節(jié)點被刪除的時候，Zookeeper通過watch機制通知它，這樣它就可以繼續(xù)完成創(chuàng)建操作（獲取鎖）。這可以讓分布式鎖在客戶端用起來就像一個本地的鎖一樣：加鎖失敗就阻塞住，直到獲取到鎖為止。這套機制，redis無法實現(xiàn)。