帶你深入理解 Redis分布式鎖...

什么是分布式鎖

說到Redis，我們第一想到的功能就是可以緩存數(shù)據(jù)，除此之外，Redis因為單進(jìn)程、性能高的特點，它還經(jīng)常被用于做分布式鎖。

鎖我們都知道，在程序中的作用就是同步工具，保證共享資源在同一時刻只能被一個線程訪問，Java中的鎖我們都很熟悉了，像synchronized 、Lock都是我們經(jīng)常使用的，但是Java的鎖只能保證單機的時候有效，分布式集群環(huán)境就無能為力了，這個時候我們就需要用到分布式鎖。

分布式鎖，顧名思義，就是分布式項目開發(fā)中用到的鎖，可以用來控制分布式系統(tǒng)之間同步訪問共享資源，一般來說，分布式鎖需要滿足的特性有這么幾點：

1、互斥性：在任何時刻，對于同一條數(shù)據(jù)，只有一臺應(yīng)用可以獲取到分布式鎖；

2、高可用性：在分布式場景下，一小部分服務(wù)器宕機不影響正常使用，這種情況就需要將提供分布式鎖的服務(wù)以集群的方式部署；

3、防止鎖超時：如果客戶端沒有主動釋放鎖，服務(wù)器會在一段時間之后自動釋放鎖，防止客戶端宕機或者網(wǎng)絡(luò)不可達(dá)時產(chǎn)生死鎖；

4、獨占性：加鎖解鎖必須由同一臺服務(wù)器進(jìn)行，也就是鎖的持有者才可以釋放鎖，不能出現(xiàn)你加的鎖，別人給你解鎖了；

業(yè)界里可以實現(xiàn)分布式鎖效果的工具很多，但操作無非這么幾個：加鎖、解鎖、防止鎖超時。

既然本文說的是Redis分布式鎖，那我們理所當(dāng)然就以Redis的知識點來延伸。

實現(xiàn)鎖的命令

先介紹下Redis的幾個命令，

1、SETNX，用法是SETNX key value

SETNX是『 SET if Not eXists』(如果不存在，則 SET)的簡寫，設(shè)置成功就返回1，否則返回0。

可以看出，當(dāng)把key為lock的值設(shè)置為"Java"后，再設(shè)置成別的值就會失敗，看上去很簡單，也好像獨占了鎖，但有個致命的問題，就是key沒有過期時間，這樣一來，除非手動刪除key或者獲取鎖后設(shè)置過期時間，不然其他線程永遠(yuǎn)拿不到鎖。

既然這樣，我們給key加個過期時間總可以吧，直接讓線程獲取鎖的時候執(zhí)行兩步操作：

SETNX?Key?1
EXPIRE?Key?Seconds

這個方案也有問題，因為獲取鎖和設(shè)置過期時間分成兩步了，不是原子性操作，有可能獲取鎖成功但設(shè)置時間失敗，那樣不就白干了嗎。

不過也不用急，這種事情Redis官方早為我們考慮到了，所以就引出了下面這個命令

2、SETEX，用法SETEX key seconds value

將值value關(guān)聯(lián)到key，并將key的生存時間設(shè)為seconds(以秒為單位)。如果key已經(jīng)存在，SETEX 命令將覆寫舊值。

這個命令類似于以下兩個命令：

SET?key?value
EXPIRE?key?seconds??#?設(shè)置生存時間

這兩步動作是原子性的，會在同一時間完成。

setex用法

3、PSETEX ，用法PSETEX key milliseconds value

這個命令和SETEX命令相似，但它以毫秒為單位設(shè)置?key?的生存時間，而不是像SETEX命令那樣，以秒為單位。

不過，從Redis 2.6.12 版本開始，SET命令可以通過參數(shù)來實現(xiàn)和SETNX、SETEX、PSETEX 三個命令相同的效果。

就比如這條命令

SET?key?value?NX?EX?seconds?

加上NX、EX參數(shù)后，效果就相當(dāng)于SETEX，這也是Redis獲取鎖寫法里面最常見的。

怎么釋放鎖

釋放鎖的命令就簡單了，直接刪除key就行，但我們前面說了，因為分布式鎖必須由鎖的持有者自己釋放，所以我們必須先確保當(dāng)前釋放鎖的線程是持有者，沒問題了再刪除，這樣一來，就變成兩個步驟了，似乎又違背了原子性了，怎么辦呢？

不慌，我們可以用lua腳本把兩步操作做拼裝，就好像這樣：

if?redis.call("get",KEYS[1])?==?ARGV[1]
then
????return?redis.call("del",KEYS[1])
else
????return?0
end

KEYS[1]是當(dāng)前key的名稱，ARGV[1]可以是當(dāng)前線程的ID(或者其他不固定的值，能識別所屬線程即可)，這樣就可以防止持有過期鎖的線程，或者其他線程誤刪現(xiàn)有鎖的情況出現(xiàn)。

代碼實現(xiàn)

知道了原理后，我們就可以手寫代碼來實現(xiàn)Redis分布式鎖的功能了，因為本文的目的主要是為了講解原理，不是為了教大家怎么寫分布式鎖，所以我就用偽代碼實現(xiàn)了。

Spring Boot Redis 實現(xiàn)分布式鎖，真香！！

首先是redis鎖的工具類，包含了加鎖和解鎖的基礎(chǔ)方法：

public?class?RedisLockUtil?{

????private?String?LOCK_KEY?=?"redis_lock";

????//?key的持有時間，5ms
????private?long?EXPIRE_TIME?=?5;

????//?等待超時時間，1s
????private?long?TIME_OUT?=?1000;

????//?redis命令參數(shù)，相當(dāng)于nx和px的命令合集
????private?SetParams?params?=?SetParams.setParams().nx().px(EXPIRE_TIME);

????//?redis連接池，連的是本地的redis客戶端
????JedisPool?jedisPool?=?new?JedisPool("127.0.0.1",?6379);

????/**
?????*?加鎖
?????*
?????*?@param?id
?????*????????????線程的id，或者其他可識別當(dāng)前線程且不重復(fù)的字段
?????*?@return
?????*/
????public?boolean?lock(String?id)?{
????????Long?start?=?System.currentTimeMillis();
????????Jedis?jedis?=?jedisPool.getResource();
????????try?{
????????????for?(;;)?{
????????????????//?SET命令返回OK?，則證明獲取鎖成功
????????????????String?lock?=?jedis.set(LOCK_KEY,?id,?params);
????????????????if?("OK".equals(lock))?{
????????????????????return?true;
????????????????}
????????????????//?否則循環(huán)等待，在TIME_OUT時間內(nèi)仍未獲取到鎖，則獲取失敗
????????????????long?l?=?System.currentTimeMillis()?-?start;
????????????????if?(l?>=?TIME_OUT)?{
????????????????????return?false;
????????????????}
????????????????try?{
????????????????????//?休眠一會，不然反復(fù)執(zhí)行循環(huán)會一直失敗
????????????????????Thread.sleep(100);
????????????????}?catch?(InterruptedException?e)?{
????????????????????e.printStackTrace();
????????????????}
????????????}
????????}?finally?{
????????????jedis.close();
????????}
????}

????/**
?????*?解鎖
?????*
?????*?@param?id
?????*????????????線程的id，或者其他可識別當(dāng)前線程且不重復(fù)的字段
?????*?@return
?????*/
????public?boolean?unlock(String?id)?{
????????Jedis?jedis?=?jedisPool.getResource();
????????//?刪除key的lua腳本
????????String?script?=?"if?redis.call('get',KEYS[1])?==?ARGV[1]?then"?+?"???return?redis.call('del',KEYS[1])?"?+?"else"
????????????+?"???return?0?"?+?"end";
????????try?{
????????????String?result?=
????????????????jedis.eval(script,?Collections.singletonList(LOCK_KEY),?Collections.singletonList(id)).toString();
????????????return?"1".equals(result);
????????}?finally?{
????????????jedis.close();
????????}
????}
}

具體的代碼作用注釋已經(jīng)寫得很清楚了，然后我們就可以寫一個demo類來測試一下效果：

public?class?RedisLockTest?{
????private?static?RedisLockUtil?demo?=?new?RedisLockUtil();
????private?static?Integer?NUM?=?101;

????public?static?void?main(String[]?args)?{
????????for?(int?i?=?0;?i?????????????new?Thread(()?->?{
????????????????String?id?=?Thread.currentThread().getId()?+?"";
????????????????boolean?isLock?=?demo.lock(id);
????????????????try?{
?????????????????//?拿到鎖的話，就對共享參數(shù)減一
????????????????????if?(isLock)?{
????????????????????????NUM--;
????????????????????????System.out.println(NUM);
????????????????????}
????????????????}?finally?{
?????????????????//?釋放鎖一定要注意放在finally
????????????????????demo.unlock(id);
????????????????}
????????????}).start();
????????}
????}
}

我們創(chuàng)建100個線程來模擬并發(fā)的情況，執(zhí)行后的結(jié)果是這樣的：

可以看出，鎖的效果達(dá)到了，線程安全是可以保證的。

當(dāng)然，上面的代碼只是簡單的實現(xiàn)了效果，功能肯定是不完整的，一個健全的分布式鎖要考慮的方面還有很多，實際設(shè)計起來不是那么容易的。

我們的目的只是為了學(xué)習(xí)和了解原理，手寫一個工業(yè)級的分布式鎖工具不現(xiàn)實，也沒必要，類似的開源工具一大堆（Redisson），原理都差不多，而且早已經(jīng)過業(yè)界同行的檢驗，直接拿來用就行。

雖然功能是實現(xiàn)了，但其實從設(shè)計上來說，這樣的分布式鎖存在著很大的缺陷，這也是本篇文章想重點探討的內(nèi)容。

分布式鎖的缺陷

一、客戶端長時間阻塞導(dǎo)致鎖失效問題

客戶端1得到了鎖，因為網(wǎng)絡(luò)問題或者GC等原因?qū)е麻L時間阻塞，然后業(yè)務(wù)程序還沒執(zhí)行完鎖就過期了，這時候客戶端2也能正常拿到鎖，可能會導(dǎo)致線程安全的問題。

那么該如何防止這樣的異常呢？我們先不說解決方案，介紹完其他的缺陷后再來討論。

二、redis服務(wù)器時鐘漂移問題

如果redis服務(wù)器的機器時鐘發(fā)生了向前跳躍，就會導(dǎo)致這個key過早超時失效，比如說客戶端1拿到鎖后，key的過期時間是12:02分，但redis服務(wù)器本身的時鐘比客戶端快了2分鐘，導(dǎo)致key在12:00的時候就失效了，這時候，如果客戶端1還沒有釋放鎖的話，就可能導(dǎo)致多個客戶端同時持有同一把鎖的問題。

三、單點實例安全問題

如果redis是單master模式的，當(dāng)這臺機宕機的時候，那么所有的客戶端都獲取不到鎖了，為了提高可用性，可能就會給這個master加一個slave，但是因為redis的主從同步是異步進(jìn)行的，可能會出現(xiàn)客戶端1設(shè)置完鎖后，master掛掉，slave提升為master，因為異步復(fù)制的特性，客戶端1設(shè)置的鎖丟失了，這時候客戶端2設(shè)置鎖也能夠成功，導(dǎo)致客戶端1和客戶端2同時擁有鎖。

為了解決Redis單點問題，redis的作者提出了RedLock算法。

RedLock算法

該算法的實現(xiàn)前提在于Redis必須是多節(jié)點部署的，可以有效防止單點故障，具體的實現(xiàn)思路是這樣的：

1、獲取當(dāng)前時間戳（ms）；

2、先設(shè)定key的有效時長（TTL），超出這個時間就會自動釋放，然后client（客戶端）嘗試使用相同的key和value對所有redis實例進(jìn)行設(shè)置，每次鏈接redis實例時設(shè)置一個比TTL短很多的超時時間，這是為了不要過長時間等待已經(jīng)關(guān)閉的redis服務(wù)。并且試著獲取下一個redis實例。

比如：TTL（也就是過期時間）為5s，那獲取鎖的超時時間就可以設(shè)置成50ms，所以如果50ms內(nèi)無法獲取鎖，就放棄獲取這個鎖，從而嘗試獲取下個鎖；

3、client通過獲取所有能獲取的鎖后的時間減去第一步的時間，還有redis服務(wù)器的時鐘漂移誤差，然后這個時間差要小于TTL時間并且成功設(shè)置鎖的實例數(shù)>= N/2 + 1（N為Redis實例的數(shù)量），那么加鎖成功

比如TTL是5s，連接redis獲取所有鎖用了2s，然后再減去時鐘漂移（假設(shè)誤差是1s左右），那么鎖的真正有效時長就只有2s了；

4、如果客戶端由于某些原因獲取鎖失敗，便會開始解鎖所有redis實例。

根據(jù)這樣的算法，我們假設(shè)有5個Redis實例的話，那么client只要獲取其中3臺以上的鎖就算是成功了，用流程圖演示大概就像這樣：?

好了，算法也介紹完了，從設(shè)計上看，毫無疑問，RedLock算法的思想主要是為了有效防止Redis單點故障的問題，而且在設(shè)計TTL的時候也考慮到了服務(wù)器時鐘漂移的誤差，讓分布式鎖的安全性提高了不少。

但事實真的是這樣嗎？反正我個人的話感覺效果一般般，

首先第一點，我們可以看到，在RedLock算法中，鎖的有效時間會減去連接Redis實例的時長，如果這個過程因為網(wǎng)絡(luò)問題導(dǎo)致耗時太長的話，那么最終留給鎖的有效時長就會大大減少，客戶端訪問共享資源的時間很短，很可能程序處理的過程中鎖就到期了。而且，鎖的有效時間還需要減去服務(wù)器的時鐘漂移，但是應(yīng)該減多少合適呢，要是這個值設(shè)置不好，很容易出現(xiàn)問題。

然后第二點，這樣的算法雖然考慮到用多節(jié)點來防止Redis單點故障的問題，但但如果有節(jié)點發(fā)生崩潰重啟的話，還是有可能出現(xiàn)多個客戶端同時獲取鎖的情況。

假設(shè)一共有5個Redis節(jié)點：A、B、C、D、E，客戶端1和2分別加鎖

1. 客戶端1成功鎖住了A，B，C，獲取鎖成功（但D和E沒有鎖住）。
2. 節(jié)點C的master掛了，然后鎖還沒同步到slave，slave升級為master后丟失了客戶端1加的鎖。
3. 客戶端2這個時候獲取鎖，鎖住了C，D，E，獲取鎖成功。

這樣，客戶端1和客戶端2就同時拿到了鎖，程序安全的隱患依然存在。除此之外，如果這些節(jié)點里面某個節(jié)點發(fā)生了時間漂移的話，也有可能導(dǎo)致鎖的安全問題。

所以說，雖然通過多實例的部署提高了可用性和可靠性，但RedLock并沒有完全解決Redis單點故障存在的隱患，也沒有解決時鐘漂移以及客戶端長時間阻塞而導(dǎo)致的鎖超時失效存在的問題，鎖的安全性隱患依然存在。

結(jié)論

有人可能要進(jìn)一步問了，那該怎么做才能保證鎖的絕對安全呢？

對此我只能說，魚和熊掌不可兼得，我們之所以用Redis作為分布式鎖的工具，很大程度上是因為Redis本身效率高且單進(jìn)程的特點，即使在高并發(fā)的情況下也能很好的保證性能，但很多時候，性能和安全不能完全兼顧，如果你一定要保證鎖的安全性的話，可以用其他的中間件如db、zookeeper來做控制，這些工具能很好的保證鎖的安全，但性能方面只能說是差強人意，否則大家早就用上了。

一般來說，用Redis控制共享資源并且還要求數(shù)據(jù)安全要求較高的話，最終的保底方案是對業(yè)務(wù)數(shù)據(jù)做冪等控制，這樣一來，即使出現(xiàn)多個客戶端獲得鎖的情況也不會影響數(shù)據(jù)的一致性。

當(dāng)然，也不是所有的場景都適合這么做，具體怎么取舍就需要各位看官自己處理啦，畢竟，沒有完美的技術(shù)，只有適合的才是最好的。

最后，關(guān)注公眾號Java技術(shù)棧，在后臺回復(fù)：面試，可以獲取我整理的 Redis 系列面試題和答案，非常齊全。

戳原文，獲取精選面試題！