Zookeeper和Redis實(shí)現(xiàn)分布式鎖，附我的可靠性分析
[導(dǎo)讀]在分布式系統(tǒng)中，為保證同一時(shí)間只有一個(gè)客戶端可以對(duì)共享資源進(jìn)行操作，需要對(duì)共享資源加鎖來實(shí)現(xiàn)，常見有三種方式：基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖基于Redis實(shí)現(xiàn)分布式鎖基于Zookeeper實(shí)現(xiàn)分布式鎖高并發(fā)下數(shù)據(jù)庫(kù)鎖性能太差，本文不做探究。僅針對(duì)Redis和Zookeeper實(shí)現(xiàn)的分布式...
在分布式系統(tǒng)中，為保證同一時(shí)間只有一個(gè)客戶端可以對(duì)共享資源進(jìn)行操作，需要對(duì)共享資源加鎖來實(shí)現(xiàn)，常見有三種方式：
-
基于數(shù)據(jù)庫(kù)實(shí)現(xiàn)分布式鎖
-
基于 Redis 實(shí)現(xiàn)分布式鎖
-
基于 Zookeeper 實(shí)現(xiàn)分布式鎖
實(shí)現(xiàn)一個(gè)分布式鎖應(yīng)該具備的特性：
-
高可用、高性能的獲取鎖與釋放鎖
-
在分布式系統(tǒng)環(huán)境下，一個(gè)方法或者變量同一時(shí)間只能被一個(gè)線程操作
-
具備鎖失效機(jī)制，網(wǎng)絡(luò)中斷或宕機(jī)無法釋放鎖時(shí)，鎖必須被刪除，防止死鎖
-
具備阻塞鎖特性，即沒有獲取到鎖，則繼續(xù)等待獲取鎖
-
具備非阻塞鎖特性，即沒有獲取到鎖，則直接返回獲取鎖失敗
-
具備可重入特性，一個(gè)線程中可以多次獲取同一把鎖，比如一個(gè)線程在執(zhí)行一個(gè)帶鎖的方法，該方法中又調(diào)用了另一個(gè)需要相同鎖的方法，則該線程可以直接執(zhí)行調(diào)用的方法，而無需重新獲得鎖
單機(jī)情況下：
1. Redis單機(jī)實(shí)現(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)，這個(gè)set()方法一共有五個(gè)形參：
-
第一個(gè)為key，使用key來當(dāng)鎖，因?yàn)閗ey是唯一的。
-
第二個(gè)為value，是由客戶端生成的一個(gè)隨機(jī)字符串，相當(dāng)于是客戶端持有鎖的標(biāo)志。用于標(biāo)識(shí)加鎖和解鎖必須是同一個(gè)客戶端。
-
第三個(gè)為nxxx，傳的是NX，意思是SET IF NOT EXIST，即當(dāng)key不存在時(shí)，進(jìn)行set操作；若key已經(jīng)存在，則不做任何操作。
-
第四個(gè)為expx，傳的是PX，意思是我們要給這個(gè)key加一個(gè)過期的設(shè)置，具體時(shí)間由第五個(gè)參數(shù)決定。
-
第五個(gè)為time，與第四個(gè)參數(shù)相呼應(yīng)，代表key的過期時(shí)間，如上30000表示這個(gè)鎖有一個(gè)30秒的自動(dòng)過期時(shí)間。
解鎖時(shí)，為了防止客戶端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腳本的時(shí)候，KEYS[1]的值為 key，ARGV[1]的值為 value。原理就是先獲取鎖對(duì)應(yīng)的value值，保證和客戶端傳進(jìn)去的value值相等，這樣就能避免自己的鎖被其他人釋放。另外，采取Lua腳本操作保證了原子性。如果不是原子性操作，則有了下述情況出現(xiàn)：
1.3 Redis加鎖過期時(shí)間設(shè)置問題理想情況是客戶端Redis加鎖后，完成一系列業(yè)務(wù)操作，順利在鎖過期時(shí)間前釋放掉鎖，這個(gè)分布式鎖的設(shè)置是有效的。但是如果客戶端在操作共享資源的過程中，因?yàn)殚L(zhǎng)期阻塞的原因，導(dǎo)致鎖過期，那么接下來訪問共享資源就變得不再安全。
2. Zookeeper單機(jī)實(shí)現(xiàn)分布式鎖
2.1 Curator實(shí)現(xiàn)Zookeeper加解鎖使用 Apache 開源的curator 可實(shí)現(xiàn) Zookeeper 分布式鎖。
可以通過調(diào)用 InterProcessLock接口提供的幾個(gè)方法來實(shí)現(xiàn)加鎖、解鎖。
/**
* 獲取鎖、阻塞等待、可重入
*/
public void acquire() throws Exception;
/**
* 獲取鎖、阻塞等待、可重入、超時(shí)則獲取失敗
*/
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加鎖實(shí)現(xiàn)原理
Zookeeper的分布式鎖原理是利用了臨時(shí)節(jié)點(diǎn)(EPHEMERAL)的特性。其實(shí)現(xiàn)原理：
-
創(chuàng)建一個(gè)鎖目錄lock
-
線程A獲取鎖會(huì)在lock目錄下，創(chuàng)建臨時(shí)順序節(jié)點(diǎn)
-
獲取鎖目錄下所有的子節(jié)點(diǎn)，然后獲取比自己小的兄弟節(jié)點(diǎn)，如果不存在，則說明當(dāng)前線程順序號(hào)最小，獲得鎖
-
線程B創(chuàng)建臨時(shí)節(jié)點(diǎn)并獲取所有兄弟節(jié)點(diǎn)，判斷自己不是最小節(jié)點(diǎn)，設(shè)置監(jiān)聽(watcher)比自己次小的節(jié)點(diǎn)（只關(guān)注比自己次小的節(jié)點(diǎn)是為了防止發(fā)生“羊群效應(yīng)”）
-
線程A處理完，刪除自己的節(jié)點(diǎn)，線程B監(jiān)聽到變更事件，判斷自己是最小的節(jié)點(diǎn)，獲得鎖
2.3 GC停頓導(dǎo)致臨時(shí)節(jié)點(diǎn)釋放問題
但是使用臨時(shí)節(jié)點(diǎn)又會(huì)存在另一個(gè)問題：Zookeeper如果長(zhǎng)時(shí)間檢測(cè)不到客戶端的心跳的時(shí)候(Session時(shí)間)，就會(huì)認(rèn)為Session過期了，那么這個(gè)Session所創(chuàng)建的所有的ephemeral類型的znode節(jié)點(diǎn)都會(huì)被自動(dòng)刪除。
如上圖所示，客戶端1發(fā)生GC停頓的時(shí)候，Zookeeper檢測(cè)不到心跳，也是有可能出現(xiàn)多個(gè)客戶端同時(shí)操作共享資源的情形。當(dāng)然，你可以說，我們可以通過JVM調(diào)優(yōu)，避免GC停頓出現(xiàn)。但是注意了，我們所做的一切，只能盡可能避免多個(gè)客戶端操作共享資源，無法完全消除。集群情況下：
3. Redis集群下分布式鎖存在問題
3.1 集群Master宕機(jī)導(dǎo)致鎖丟失為了Redis的高可用，一般都會(huì)給Redis的節(jié)點(diǎn)掛一個(gè)slave,然后采用哨兵模式進(jìn)行主備切換。但由于Redis的主從復(fù)制（replication）是異步的，這可能會(huì)出現(xiàn)在數(shù)據(jù)同步過程中，master宕機(jī)，slave來不及同步數(shù)據(jù)就被選為master，從而數(shù)據(jù)丟失。具體流程如下所示：
-
(1)客戶端1從Master獲取了鎖。
-
(2)Master宕機(jī)了，存儲(chǔ)鎖的key還沒有來得及同步到Slave上。
-
(3)Slave升級(jí)為Master。
-
(4)客戶端1的鎖丟失，客戶端2從新的Master獲取到了對(duì)應(yīng)同一個(gè)資源的鎖。
為了應(yīng)對(duì)這個(gè)情形， Redis作者antirez基于分布式環(huán)境下提出了一種更高級(jí)的分布式鎖的實(shí)現(xiàn)方式：Redlock。
antirez提出的redlock算法大概是這樣的：
在Redis的分布式環(huán)境中，我們假設(shè)有N個(gè)Redis master。這些節(jié)點(diǎn)完全互相獨(dú)立，不存在主從復(fù)制或者其他集群協(xié)調(diào)機(jī)制。我們確保將在N個(gè)實(shí)例上使用與在Redis單實(shí)例下相同方法獲取和釋放鎖。現(xiàn)在我們假設(shè)有5個(gè)Redis master節(jié)點(diǎn)(官方文檔里將N設(shè)置成5，其實(shí)大等于3就行)，同時(shí)我們需要在5臺(tái)服務(wù)器上面運(yùn)行這些Redis實(shí)例，這樣保證他們不會(huì)同時(shí)都宕掉。
為了取到鎖，客戶端應(yīng)該執(zhí)行以下操作:
-
(1)獲取當(dāng)前Unix時(shí)間，以毫秒為單位。
-
(2)依次嘗試從5個(gè)實(shí)例，使用相同的key和具有唯一性的value（例如UUID）獲取鎖。當(dāng)向Redis請(qǐng)求獲取鎖時(shí)，客戶端應(yīng)該設(shè)置一個(gè)網(wǎng)絡(luò)連接和響應(yīng)超時(shí)時(shí)間，這個(gè)超時(shí)時(shí)間應(yīng)該小于鎖的失效時(shí)間。例如你的鎖自動(dòng)失效時(shí)間為10秒，則超時(shí)時(shí)間應(yīng)該在5-50毫秒之間。這樣可以避免服務(wù)器端Redis已經(jīng)掛掉的情況下，客戶端還在死死地等待響應(yīng)結(jié)果。如果服務(wù)器端沒有在規(guī)定時(shí)間內(nèi)響應(yīng)，客戶端應(yīng)該盡快嘗試去另外一個(gè)Redis實(shí)例請(qǐng)求獲取鎖。
-
(3)客戶端使用當(dāng)前時(shí)間減去開始獲取鎖時(shí)間（步驟1記錄的時(shí)間）就得到獲取鎖使用的時(shí)間。當(dāng)且僅當(dāng)從大多數(shù)（N/2 1，這里是3個(gè)節(jié)點(diǎn)）的Redis節(jié)點(diǎn)都取到鎖，并且使用的時(shí)間小于鎖失效時(shí)間時(shí)，鎖才算獲取成功。
-
(4)如果取到了鎖，key的真正有效時(shí)間等于有效時(shí)間減去獲取鎖所使用的時(shí)間（步驟3計(jì)算的結(jié)果）。
-
(5)如果因?yàn)槟承┰?，獲取鎖失?。]有在至少N/2 1個(gè)Redis實(shí)例取到鎖或者取鎖時(shí)間已經(jīng)超過了有效時(shí)間），客戶端應(yīng)該在所有的Redis實(shí)例上進(jìn)行解鎖（即便某些Redis實(shí)例根本就沒有加鎖成功，防止某些節(jié)點(diǎn)獲取到鎖但是客戶端沒有得到響應(yīng)而導(dǎo)致接下來的一段時(shí)間不能被重新獲取鎖）。
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是鎖失效時(shí)間。
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é)點(diǎn)崩潰重啟，會(huì)出現(xiàn)多個(gè)客戶端持有鎖 假設(shè)一共有5個(gè)Redis節(jié)點(diǎn)：A, B, C, D, E。設(shè)想發(fā)生了如下的事件序列：
-
(1)客戶端1成功鎖住了A, B, C，獲取鎖成功（但D和E沒有鎖住）。
-
(2)節(jié)點(diǎn)C崩潰重啟了，但客戶端1在C上加的鎖沒有持久化下來，丟失了。
-
(3)節(jié)點(diǎn)C重啟后，客戶端2鎖住了C, D, E，獲取鎖成功。
為了應(yīng)對(duì)節(jié)點(diǎn)重啟引發(fā)的鎖失效問題，redis的作者antirez提出了延遲重啟的概念，即一個(gè)節(jié)點(diǎn)崩潰后，先不立即重啟它，而是等待一段時(shí)間再重啟，等待的時(shí)間大于鎖的有效時(shí)間。采用這種方式，這個(gè)節(jié)點(diǎn)在重啟前所參與的鎖都會(huì)過期，它在重啟后就不會(huì)對(duì)現(xiàn)有的鎖造成影響。這其實(shí)也是通過人為補(bǔ)償措施，降低不一致發(fā)生的概率。時(shí)間跳躍問題
-
(1)假設(shè)一共有5個(gè)Redis節(jié)點(diǎn)：A, B, C, D, E。設(shè)想發(fā)生了如下的事件序列：
-
(2)客戶端1從Redis節(jié)點(diǎn)A, B, C成功獲取了鎖（多數(shù)節(jié)點(diǎn)）。由于網(wǎng)絡(luò)問題，與D和E通信失敗。
-
(3)節(jié)點(diǎn)C上的時(shí)鐘發(fā)生了向前跳躍，導(dǎo)致它上面維護(hù)的鎖快速過期。
-
(4)客戶端2從Redis節(jié)點(diǎn)C, D, E成功獲取了同一個(gè)資源的鎖（多數(shù)節(jié)點(diǎn)）。
-
(5)客戶端1和客戶端2現(xiàn)在都認(rèn)為自己持有了鎖。
如圖所示，我們將其分為上下兩個(gè)部分。對(duì)于上半部分框圖里的步驟來說，無論因?yàn)槭裁丛虬l(fā)生了延遲，RedLock算法都能處理，客戶端不會(huì)拿到一個(gè)它認(rèn)為有效，實(shí)際卻失效的鎖。然而，對(duì)于下半部分框圖里的步驟來說，如果發(fā)生了延遲導(dǎo)致鎖失效，都有可能使得客戶端2拿到鎖。因此，RedLock算法并沒有解決該問題。4. Zookeeper集群下分布式鎖可靠性分析
4.1 Zookeeper的寫數(shù)據(jù)的原理Zookeeper在集群部署中，Zookeeper節(jié)點(diǎn)數(shù)量一般是奇數(shù)，且一定大等于3。下面是Zookeeper的寫數(shù)據(jù)的原理：
那么寫數(shù)據(jù)流程步驟如下：-
(1)在Client向Follwer發(fā)出一個(gè)寫的請(qǐng)求
-
(2)Follwer把請(qǐng)求發(fā)送給Leader
-
(3)Leader接收到以后開始發(fā)起投票并通知Follwer進(jìn)行投票
-
(4)Follwer把投票結(jié)果發(fā)送給Leader，只要半數(shù)以上返回了ACK信息，就認(rèn)為通過
-
(5)Leader將結(jié)果匯總后如果需要寫入，則開始寫入同時(shí)把寫入操作通知給Leader，然后commit;
-
(6)Follwer把請(qǐng)求結(jié)果返回給Client
4.2 集群模式下Zookeeper可靠性分析
下面列出Redis集群下分布式鎖可能存在的問題，判斷其在Zookeeper集群下是否會(huì)存在：
集群同步
-
client給Follwer寫數(shù)據(jù)，可是Follwer卻宕機(jī)了，會(huì)出現(xiàn)數(shù)據(jù)不一致問題么？不可能，這種時(shí)候，client建立節(jié)點(diǎn)失敗，根本獲取不到鎖。
-
client給Follwer寫數(shù)據(jù)，F(xiàn)ollwer將請(qǐng)求轉(zhuǎn)發(fā)給Leader，Leader宕機(jī)了，會(huì)出現(xiàn)不一致的問題么？不可能，這種時(shí)候，Zookeeper會(huì)選取新的leader，繼續(xù)上面的提到的寫流程。
5. 鎖的其他特性比較
redis的讀寫性能比Zookeeper強(qiáng)太多，如果在高并發(fā)場(chǎng)景中，使用Zookeeper作為分布式鎖，那么會(huì)出現(xiàn)獲取鎖失敗的情況，存在性能瓶頸。Zookeeper可以實(shí)現(xiàn)讀寫鎖，Redis不行。
Zookeeper的watch機(jī)制,客戶端試圖創(chuàng)建znode的時(shí)候，發(fā)現(xiàn)它已經(jīng)存在了，這時(shí)候創(chuàng)建失敗,那么進(jìn)入一種等待狀態(tài)，當(dāng)znode節(jié)點(diǎn)被刪除的時(shí)候，Zookeeper通過watch機(jī)制通知它，這樣它就可以繼續(xù)完成創(chuàng)建操作（獲取鎖）。這可以讓分布式鎖在客戶端用起來就像一個(gè)本地的鎖一樣：加鎖失敗就阻塞住，直到獲取到鎖為止。這套機(jī)制，redis無法實(shí)現(xiàn)。
下載文檔
