一、分布式鎖的作用：

同一時間只允許一個用戶操作，

一般情況下，我們使用分布式鎖主要有兩個場景：

避免不同節(jié)點重復相同的工作：比如用戶執(zhí)行了某個操作有可能不同節(jié)點會發(fā)送多封郵件；

避免破壞數(shù)據(jù)的正確性：如果兩個節(jié)點在同一條數(shù)據(jù)上同時進行操作，可能會造成數(shù)據(jù)錯誤或不一致的情況出現(xiàn)

二、分布式鎖的實現(xiàn)方式

基于 MySQL 中的鎖：MySQL 本身有自帶的悲觀鎖?for update?關鍵字，也可以自己實現(xiàn)悲觀/樂觀鎖來達到目的；

基于 Zookeeper 有序節(jié)點：Zookeeper 允許臨時創(chuàng)建有序的子節(jié)點，這樣客戶端獲取節(jié)點列表時，就能夠當前子節(jié)點列表中的序號判斷是否能夠獲得鎖；

基于 Redis 的單線程：由于 Redis 是單線程，所以命令會以串行的方式執(zhí)行，并且本身提供了像?SETNX(set if not exists)?、Expire這樣的指令，本身具有互斥性（因為SETNX和EXPIRE組合不是原子的，因此出現(xiàn)了SET key value?EX?6?NX指令是原子的）；

三、redis分布式鎖的問題

（1）鎖超時：

假設現(xiàn)在我們有兩臺平行的服務 A B，其中 A 服務在?獲取鎖之后?突然?掛了，那么 B 服務就永遠無法獲取到鎖了：

如果在加鎖和釋放鎖之間的邏輯執(zhí)行得太長，以至于超出了鎖的超時限制，也會出現(xiàn)問題。因為這時候第一個線程持有鎖過期了，而臨界區(qū)的邏輯還沒有執(zhí)行完，與此同時第二個線程就提前擁有了這把鎖，導致臨界區(qū)的代碼不能得到嚴格的串行執(zhí)行。因此Redis 分布式鎖不要用于較長時間的任務

GC可能引發(fā)的問題：服務 A 獲取了鎖并設置了超時時間，但是服務 A 出現(xiàn)了 STW 且時間較長，導致了分布式鎖進行了超時釋放，在這個期間服務 B 獲取到了鎖，待服務 A STW 結束之后又恢復了鎖，這就導致了?服務 A 和服務 B 同時獲取到了鎖，這個時候分布式鎖就不安全了。

（2）單點和多點宕機問題對分布式鎖的影響：

如果 Redis 采用單機部署模式也就是單點鎖，那就意味著當 Redis 故障了，就會導致整個服務不可用。

而如果采用主從模式部署，我們想象一個這樣的場景：服務 A?申請到一把鎖之后，如果作為主機的 Redis 宕機了，那么?服務 B?在申請鎖的時候就會從 從機那里獲取到這把鎖，從而導致服務AB同時獲取了鎖，為了解決這個問題，Redis 作者提出了一種?RedLock 紅鎖?的算法?(Redission 同 Jedis)

四、redLock紅鎖

一種基于 Redis 實現(xiàn)分布式鎖的方式。

比原先的單節(jié)點的方法更安全。它可以保證以下特性：

安全特性：互斥訪問，即永遠只有一個 client 能拿到鎖

避免死鎖：最終 client 都可能拿到鎖，不會出現(xiàn)死鎖的情況，即使原本鎖住某資源的 client crash 了或者出現(xiàn)了網(wǎng)絡分區(qū)

容錯性：只要大部分 Redis 節(jié)點存活就可以正常提供服務

redlock算法：

假設有5個完全獨立的redis主服務器，為了獲得鎖，client 會進行如下操作

1.獲取當前時間戳

2.client嘗試順序的使用相同的key,value申請所有redis服務的鎖，在獲取鎖的過程中的獲取時間比鎖過期時間timeout短很多，是為了不要過長時間的等待已經(jīng)關閉的redis服務。并且試著獲取下一個redis實例。

? ?比如：timeout為5s,設置獲取鎖最多用1s，所以如果一秒內無法獲取鎖，就放棄獲取這個鎖，從而嘗試獲取下個鎖

3.當 client 在大于等于 3 個 master 上成功申請到鎖的時候，會計算申請鎖消耗了多少時間，這部分消耗的時間采用獲得鎖的當下時間戳減去第一步獲得的時間戳得到，如果申請花費的時間小于timeout的時間，那么鎖就真正獲取到了。

4.如果成功獲取鎖，則鎖的真正有效時間是 timeout時間減去申請鎖花費的時間；比如：timeout是5s,獲取所有鎖用了2s,則真正鎖有效時間為3s(其實應該再減去時鐘漂移);

5.如果 client 申請分布式鎖失敗了，那么它就會在少部分申請成功鎖的 master 節(jié)點上執(zhí)行釋放鎖的操作，重置狀態(tài)

6.失敗重試：如果一個 client 申請鎖失敗了，那么它需要稍等一會再重試避免多個 client 同時申請鎖的情況，另外就是如果 client 申請鎖失敗了它需要盡快在它曾經(jīng)申請到鎖的 master 上執(zhí)行 unlock 操作，便于其他 client 獲得這把鎖，避免這些鎖過期造成的時間浪費

7.崩潰恢復：如果我們的節(jié)點沒有持久化機制，client 從 5 個 master 中的 3 個處獲得了鎖，然后其中一個重啟了，這是注意?整個環(huán)境中又出現(xiàn)了 3 個 master 可供另一個 client 申請同一把鎖！?違反了互斥性。

如果我們開啟了 AOF 持久化那么情況會稍微好轉一些，因為 Redis 的過期機制是語義層面實現(xiàn)的，所以在 server 掛了的時候時間依舊在流逝，重啟之后鎖狀態(tài)不會受到污染。但是考慮斷電之后呢，AOF部分命令沒來得及刷回磁盤直接丟失了，除非我們配置刷回策略為 fsnyc = always，但這會損傷性能。

解決這個問題的方法是，當一個節(jié)點重啟之后，我們規(guī)定在 max timeout期間它是不可用的（不可以被獲取鎖的），這樣它就不會干擾原本已經(jīng)申請到的鎖，等到它 crash 前的那部分鎖都過期了，環(huán)境不存在歷史鎖了，那么再把這個節(jié)點加進來正常工作。

?

總結

以上是生活随笔為你收集整理的redis相关知识记录整理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。