您好,登錄后才能下訂單哦!
之前我們使用的定時任務都是只部署在了單臺機器上,為了解決單點的問題,為了保證一個任務,只被一臺機器執行,就需要考慮鎖的問題,于是就花時間研究了這個問題。到底怎樣實現一個分布式鎖呢?
鎖的本質就是互斥,保證任何時候能有一個客戶端持有同一個鎖,如果考慮使用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釋放了。
鎖的釋放必須使用lua腳本,保證操作的原子性。鎖的釋放包含了get,判斷,del三個步驟。如果不能保證三個步驟的原子性,分布式鎖就會有并發問題。
注意了以上細節,一個單redis節點的分布式鎖就達成了。
在這個分布式鎖中還是存在一個單點的redis。也許你會說,Redis是 master-slave的架構,發生故障的時候切換到slave就好,但是Redis的復制是異步的。
這樣由于Master的宕機,造成了同時多人持有鎖。如果你的系統可用接受短時時間內,有多人持有鎖。這個簡單的方案就能解決問題。
但是如果解決這個問題。Redis的官方提供了一個Redlock的解決方案。
RedLock 的實現
為了解決,Redis單點的問題。Redis的作者提出了RedLock的解決方案。方案非常的巧妙和簡潔。
RedLock的核心思想就是,同時使用多個Redis Master來冗余,且這些節點都是完全的獨立的,也不需要對這些節點之間的數據進行同步。
假設我們有N個Redis節點,N應該是一個大于2的奇數。RedLock的實現步驟:
對于釋放鎖的實現就很簡單了。想所有的Redis節點發起釋放的操作,無論之前是否獲取鎖成功。
同時需要注意幾個細節:
重試獲取鎖的間隔時間應當是一個隨機范圍而非一個固定時間。這樣可以防止,多客戶端同時一起向Redis集群發送獲取鎖的操作,避免同時競爭。同時獲取相同數量鎖的情況。(雖然概率很低)
如果某master節點故障之后,回復的時間間隔應當大于鎖的有效時間。
所以如果恢復的時間將大于鎖的有效時間,就可以避免以上情況發生。同時如果性能要求不高,甚至可以開啟Redis的持久化選項。
總結
了解了Redis分布式的實現以后,其實覺得大多數的分布式系統其實原理很簡單,但是為了保證分布式系統的可靠性需要注意很多的細節,瑣碎異常。
RedLock算法實現的分布式鎖就是簡單高效,思路相當巧妙。
但是RedLock就一定安全么?我還會寫一篇文章來討論這個問題。敬請大家期待。
以上就是本文的全部內容,希望對大家的學習有所幫助,也希望大家多多支持億速云。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。