Redis 分佈式鎖的正確實現方式

之前我們使用的定時任務都是隻部署在了單臺機器上,爲了解決單點的問題,爲了保證一個任務,只被一臺機器執行,就需要考慮鎖的問題,於是就花時間研究了這個問題。到底怎樣實現一個分佈式鎖呢?

閱讀這篇文章你可以瞭解到:

  • 單機版的實現
  • 分佈式環境下RedLock實現

鎖的本質就是互斥,保證任何時候能有一個客戶端持有同一個鎖,如果考慮使用redis來實現一個分佈式鎖,最簡單的方案就是在實例裏面創建一個鍵值,釋放鎖的時候,將鍵值刪除。但是一個可靠完善的分佈式鎖需要考慮的細節比較多,我們就來看看如何寫一個正確的分佈式鎖。

單機版分佈式鎖 SETNX

所以我們直接基於 redis 的 setNX (SET if Not eXists)命令,實現一個簡單的鎖。直接上僞碼

鎖的獲取:

    SET resource_name my_random_value NX PX 30000

鎖的釋放:

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

幾個細節需要注意:

  • 首先在獲取鎖的時候我們需要設置設置超時時間。設置超時時間是爲了,防止客戶端崩潰,或者網絡出現問題以後鎖一直被持有。真個系統就死鎖了。
  • 使用 setNX 命令,保證查詢和寫入兩個步驟是原子的
  • 在鎖釋放的時候我們判斷了KEYS[1]) == ARGV[1],在這裏 KEYS[1]是從redis裏面取出來的value,ARGV[1]是上文生成的my_random_value。之所以進行以上的判斷,是爲了保證鎖被鎖的持有者釋放。我們假設不進行這一步校驗: 造成這個問題的關鍵,在於客戶端B持有的鎖,被客戶端A釋放了。
    1. 客戶端A獲取鎖,後發線程掛起了。時間大於鎖的過期時間。
    2. 鎖過期後,客戶端B獲取鎖。
    3. 客戶端A恢復以後,處理完相關事件,向redis發起 del命令。鎖被釋放
    4. 客戶端C獲取鎖。這個時候一個系統中同時兩個客戶端持有鎖。
  • 鎖的釋放必須使用lua腳本,保證操作的原子性。鎖的釋放包含了get,判斷,del三個步驟。如果不能保證三個步驟的原子性,分佈式鎖就會有併發問題。

注意了以上細節,一個單redis節點的分佈式鎖就達成了。

在這個分佈式鎖中還是存在一個單點的redis。也許你會說,Redis是 master-slave的架構,發生故障的時候切換到slave就好,但是Redis的複製是異步的。

  • 如果在客戶端A在master上拿到了鎖。
  • 在master將數據同步到slave上之前,master宕機。
  • 客戶端B就從slave上又一次拿到了鎖。

這樣由於Master的宕機,造成了同時多人持有鎖。如果你的系統可用接受短時時間內,有多人持有鎖。這個簡單的方案就能解決問題。

但是如果解決這個問題。Redis的官方提供了一個Redlock的解決方案。

RedLock 的實現

爲了解決,Redis單點的問題。Redis的作者提出了RedLock的解決方案。方案非常的巧妙和簡潔。 RedLock的核心思想就是,同時使用多個Redis Master來冗餘,且這些節點都是完全的獨立的,也不需要對這些節點之間的數據進行同步。

假設我們有N個Redis節點,N應該是一個大於2的奇數。RedLock的實現步驟:

  1. 取得當前時間
  2. 使用上文提到的方法依次獲取N個節點的Redis鎖。
  3. 如果獲取到的鎖的數量大於 (N/2+1)個,且獲取的時間小於鎖的有效時間(lock validity time)就認爲獲取到了一個有效的鎖。鎖自動釋放時間就是最初的鎖釋放時間減去之前獲取鎖所消耗的時間。
  4. 如果獲取鎖的數量小於 (N/2+1),或者在鎖的有效時間(lock validity time)內沒有獲取到足夠的說,就認爲獲取鎖失敗。這個時候需要向所有節點發送釋放鎖的消息。

對於釋放鎖的實現就很簡單了。想所有的Redis節點發起釋放的操作,無論之前是否獲取鎖成功。

同時需要注意幾個細節:

  • 重試獲取鎖的間隔時間應當是一個隨機範圍而非一個固定時間。這樣可以防止,多客戶端同時一起向Redis集羣發送獲取鎖的操作,避免同時競爭。同時獲取相同數量鎖的情況。(雖然概率很低)
  • 如果某master節點故障之後,回覆的時間間隔應當大於鎖的有效時間。 所以如果恢復的時間將大於鎖的有效時間,就可以避免以上情況發生。同時如果性能要求不高,甚至可以開啓Redis的持久化選項。
    1. 假設有A,B,C三個Redis節點。
    2. 客戶端foo獲取到了A、B兩個鎖。
    3. 這個時候B宕機,所有內存的數據丟失。
    4. B節點恢復。
    5. 這個時候客戶端bar重新獲取鎖,獲取到B,C兩個節點。
    6. 此時又有兩個客戶端獲取到鎖了。

總結

瞭解了Redis分佈式的實現以後,其實覺得大多數的分佈式系統其實原理很簡單,但是爲了保證分佈式系統的可靠性需要注意很多的細節,瑣碎異常。 RedLock算法實現的分佈式鎖就是簡單高效,思路相當巧妙。 但是RedLock就一定安全麼?我還會寫一篇文章來討論這個問題。敬請大家期待。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章