帶你深入瞭解Redis中的分散式鎖

什麼是分散式鎖

說到Redis，我們第一想到的功能就是可以快取資料，除此之外，Redis因為單程序、效能高的特點，它還經常被用於做分散式鎖。【相關推薦：Redis視訊教學】

鎖我們都知道，在程式中的作用就是同步工具，保證共用資源在同一時刻只能被一個執行緒存取，Java中的鎖我們都很熟悉了，像synchronized 、Lock都是我們經常使用的，但是Java的鎖只能保證單機的時候有效，分散式叢集環境就無能為力了，這個時候我們就需要用到分散式鎖。

分散式鎖，顧名思義，就是分散式專案開發中用到的鎖，可以用來控制分散式系統之間同步存取共用資源，一般來說，分散式鎖需要滿足的特性有這麼幾點：

1、互斥性：在任何時刻，對於同一條資料，只有一臺應用可以獲取到分散式鎖；

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

3、防止鎖超時：如果使用者端沒有主動釋放鎖，伺服器會在一段時間之後自動釋放鎖，防止使用者端宕機或者網路不可達時產生死鎖；

4、獨佔性：加鎖解鎖必須由同一臺伺服器進行，也就是鎖的持有者才可以釋放鎖，不能出現你加的鎖，別人給你解鎖了；

業界裡可以實現分散式鎖效果的工具很多，但操作無非這麼幾個：加鎖、解鎖、防止鎖超時。

既然本文說的是Redis分散式鎖，那我們理所當然就以Redis的知識點來延伸。

實現鎖的命令

先介紹下Redis的幾個命令，

1、SETNX，用法是SETNX key value

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

setnx用法

可以看出，當把key為lock的值設定為"Java"後，再設定成別的值就會失敗，看上去很簡單，也好像獨佔了鎖，但有個致命的問題，就是key沒有過期時間，這樣一來，除非手動刪除key或者獲取鎖後設定過期時間，不然其他執行緒永遠拿不到鎖。

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

`SETNX Key 1`
`EXPIRE Key Seconds`

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

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

2、SETEX，用法SETEX key seconds value

將值 value 關聯到 key ，並將 key 的生存時間設為 seconds (以秒為單位)。如果 key 已經存在，SETEX 命令將覆寫舊值。

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

`SET key value`
`EXPIRE key seconds  # 設定生存時間`

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

setex用法

3、PSETEX ，用法PSETEX key milliseconds value

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

不過，從Redis 2.6.12 版本開始，SET命令可以通過引數來實現和SETNX、SETEX、PSETEX 三個命令相同的效果。

就比如這條命令

`SET key value NX EX seconds`

加上NX、EX引數後，效果就相當於SETEX，這也是Redis獲取鎖寫法裡面最常見的。

怎麼釋放鎖

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

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

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

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

程式碼實現

知道了原理後，我們就可以手寫程式碼來實現Redis分散式鎖的功能了，因為本文的目的主要是為了講解原理，不是為了教大家怎麼寫分散式鎖，所以我就用虛擬碼實現了。

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

`public class RedisLockUtil {`
 `private String LOCK_KEY = "redis_lock";`
 `// key的持有時間，5ms`
 `private long EXPIRE_TIME = 5;`
 `// 等待超時時間，1s`
 `private long TIME_OUT = 1000;`
 `// redis命令引數，相當於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，或者其他可識別當前執行緒且不重複的欄位`
 `* @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;`
 `}`
 `// 否則迴圈等待，在TIME_OUT時間內仍未獲取到鎖，則獲取失敗`
 `long l = System.currentTimeMillis() - start;`
 `if (l >= TIME_OUT) {`
 `return false;`
 `}`
 `try {`
 `// 休眠一會，不然反覆執行迴圈會一直失敗`
 `Thread.sleep(100);`
 `} catch (InterruptedException e) {`
 `e.printStackTrace();`
 `}`
 `}`
 `} finally {`
 `jedis.close();`
 `}`
 `}`
 `/**`
 `* 解鎖`
 `*`
 `* @param id`
 `*            執行緒的id，或者其他可識別當前執行緒且不重複的欄位`
 `* @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();`
 `}`
 `}`
`}`

具體的程式碼作用註釋已經寫得很清楚了，然後我們就可以寫一個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 < 100; i++) {`
 `new Thread(() -> {`
 `String id = Thread.currentThread().getId() + "";`
 `boolean isLock = demo.lock(id);`
 `try {`
 `// 拿到鎖的話，就對共用引數減一`
 `if (isLock) {`
 `NUM--;`
 `System.out.println(NUM);`
 `}`
 `} finally {`
 `// 釋放鎖一定要注意放在finally`
 `demo.unlock(id);`
 `}`
 `}).start();`
 `}`
 `}`
`}`

我們建立100個執行緒來模擬並行的情況，執行後的結果是這樣的：

程式碼執行結果

可以看出，鎖的效果達到了，執行緒安全是可以保證的。

當然，上面的程式碼只是簡單的實現了效果，功能肯定是不完整的，一個健全的分散式鎖要考慮的方面還有很多，實際設計起來不是那麼容易的。

我們的目的只是為了學習和了解原理，手寫一個工業級的分散式鎖工具不現實，也沒必要，類似的開源工具一大堆（Redisson），原理都差不多，而且早已經過業界同行的檢驗，直接拿來用就行。

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

分散式鎖的缺陷

一、使用者端長時間阻塞導致鎖失效問題

使用者端1得到了鎖，因為網路問題或者GC等原因導致長時間阻塞，然後業務程式還沒執行完鎖就過期了，這時候使用者端2也能正常拿到鎖，可能會導致執行緒安全的問題。

使用者端長時間阻塞

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

二、redis伺服器時鐘漂移問題

如果redis伺服器的機器時鐘發生了向前跳躍，就會導致這個key過早超時失效，比如說使用者端1拿到鎖後，key的過期時間是12:02分，但redis伺服器本身的時鐘比使用者端快了2分鐘，導致key在12:00的時候就失效了，這時候，如果使用者端1還沒有釋放鎖的話，就可能導致多個使用者端同時持有同一把鎖的問題。

三、單點範例安全問題

如果redis是單master模式的，當這臺機宕機的時候，那麼所有的使用者端都獲取不到鎖了，為了提高可用性，可能就會給這個master加一個slave，但是因為redis的主從同步是非同步進行的，可能會出現使用者端1設定完鎖後，master掛掉，slave提升為master，因為非同步複製的特性，使用者端1設定的鎖丟失了，這時候使用者端2設定鎖也能夠成功，導致使用者端1和使用者端2同時擁有鎖。

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

RedLock演演算法

該演演算法的實現前提在於Redis必須是多節點部署的，可以有效防止單點故障，具體的實現思路是這樣的：

1、獲取當前時間戳（ms）；

2、先設定key的有效時長（TTL），超出這個時間就會自動釋放，然後client（使用者端）嘗試使用相同的key和value對所有redis範例進行設定，每次連結redis範例時設定一個比TTL短很多的超時時間，這是為了不要過長時間等待已經關閉的redis服務。並且試著獲取下一個redis範例。

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

3、client通過獲取所有能獲取的鎖後的時間減去第一步的時間，還有redis伺服器的時鐘漂移誤差，然後這個時間差要小於TTL時間並且成功設定鎖的範例數>= N/2 + 1（N為Redis範例的數量），那麼加鎖成功

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

4、如果使用者端由於某些原因獲取鎖失敗，便會開始解鎖所有redis範例。

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

key有效時長

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

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

首先第一點，我們可以看到，在RedLock演演算法中，鎖的有效時間會減去連線Redis範例的時長，如果這個過程因為網路問題導致耗時太長的話，那麼最終留給鎖的有效時長就會大大減少，使用者端存取共用資源的時間很短，很可能程式處理的過程中鎖就到期了。而且，鎖的有效時間還需要減去伺服器的時鐘漂移，但是應該減多少合適呢，要是這個值設定不好，很容易出現問題。

然後第二點，這樣的演演算法雖然考慮到用多節點來防止Redis單點故障的問題，但但如果有節點發生崩潰重新啟動的話，還是有可能出現多個使用者端同時獲取鎖的情況。

假設一共有5個Redis節點：A、B、C、D、E，使用者端1和2分別加鎖

• 使用者端1成功鎖住了A，B，C，獲取鎖成功（但D和E沒有鎖住）。

• 節點C的master掛了，然後鎖還沒同步到slave，slave升級為master後丟失了使用者端1加的鎖。

• 使用者端2這個時候獲取鎖，鎖住了C，D，E，獲取鎖成功。

這樣，使用者端1和使用者端2就同時拿到了鎖，程式安全的隱患依然存在。除此之外，如果這些節點裡面某個節點發生了時間漂移的話，也有可能導致鎖的安全問題。

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

結論

有人可能要進一步問了，那該怎麼做才能保證鎖的絕對安全呢？

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

一般來說，用Redis控制共用資源並且還要求資料安全要求較高的話，最終的保底方案是對業務資料做冪等控制，這樣一來，即使出現多個使用者端獲得鎖的情況也不會影響資料的一致性。當然，也不是所有的場景都適合這麼做，具體怎麼取捨就需要各位看官自己處理啦，畢竟，沒有完美的技術，只有適合的才是最好的。

更多程式設計相關知識，請存取：！！

以上就是帶你深入瞭解Redis中的分散式鎖的詳細內容，更多請關注TW511.COM其它相關文章！