用 Redis 實現分散式鎖與實現任務佇列

發表於2015-11-24

這一次總結和分享用Redis實現分散式鎖 與 實現任務佇列 這兩大強大的功能。先扯點個人觀點,之前我看了一篇博文說部落格園的文章大部分都是分享程式碼,博文裡強調說分享思路比分享程式碼更重要(貌似大概是這個意思,若有誤請諒解),但我覺得,分享思路固然重要,但有了思路,卻沒有實現的程式碼,那會讓人覺得很浮誇的,在工作中的程式猿都知道,你去實現一個功能模組,一段程式碼,雖然你有了思路,但是實現的過程也是很耗時的,特別是程式碼除錯,還有各種測試等等。所以我認為,思路+程式碼,才是一篇好博文的主要核心。

  直接進入主題。

  一、前言

  雙十一剛過不久,大家都知道在天貓、京東、蘇寧等等電商網站上有很多秒殺活動,例如在某一個時刻搶購一個原價1999現在秒殺價只要999的手機時,會迎來一個使用者請求的高峰期,可能會有幾十萬幾百萬的併發量,來搶這個手機,在高併發的情形下會對資料庫伺服器或者是檔案伺服器應用伺服器造成巨大的壓力,嚴重時說不定就當機了,另一個問題是,秒殺的東西都是有量的,例如一款手機只有10臺的量秒殺,那麼,在高併發的情況下,成千上萬條資料更新資料庫(例如10臺的量被人搶一臺就會在資料集某些記錄下 減1),那次這個時候的先後順序是很亂的,很容易出現10臺的量,搶到的人就不止10個這種嚴重的問題。那麼,以後所說的問題我們該如何去解決呢? 接下來我所分享的技術就可以拿來處理以上的問題: 分散式鎖 和 任務佇列。

  二、實現思路

  1.Redis實現分散式鎖思路

  思路很簡單,主要用到的redis函式是setnx(),這個應該是實現分散式鎖最主要的函式。首先是將某一任務標識名(這裡用Lock:order作為標識名的例子)作為鍵存到redis裡,併為其設個過期時間,如果是還有Lock:order請求過來,先是通過setnx()看看是否能將Lock:order插入到redis裡,可以的話就返回true,不可以就返回false。當然,在我的程式碼裡會比這個思路複雜一些,我會在分析程式碼時進一步說明。

  2.Redis實現任務佇列

  這裡的實現會用到上面的Redis分散式的鎖機制,主要是用到了Redis裡的有序集合這一資料結構。例如入隊時,通過zset的add()函式進行入隊,而出對時,可以用到zset的getScore()函式。另外還可以彈出頂部的幾個任務。

  以上就是實現 分散式鎖 和 任務佇列 的簡單思路,如果你看完有點模稜兩可,那請看接下來的程式碼實現。

  三、程式碼分析

  (一)先來分析Redis分散式鎖的程式碼實現  

  (1)為避免特殊原因導致鎖無法釋放,在加鎖成功後,鎖會被賦予一個生存時間(通過lock方法的引數設定或者使用預設值),超出生存時間鎖會被自動釋放鎖的生存時間預設比較短(秒級),因此,若需要長時間加鎖,可以通過expire方法延長鎖的生存時間為適當時間,比如在迴圈內。

  (2)系統級的鎖當程式無論何種原因時出現crash時,作業系統會自己回收鎖,所以不會出現資源丟失,但分散式鎖不用,若一次性設定很長時間,一旦由於各種原因出現程式crash 或者其他異常導致unlock未被呼叫時,則該鎖在剩下的時間就會變成垃圾鎖,導致其他程式或者程式重啟後無法進入加鎖區域。

  先看加鎖的實現程式碼:這裡需要主要兩個引數,一個是$timeout,這個是迴圈獲取鎖的等待時間,在這個時間內會一直嘗試獲取鎖知道超時,如果為0,則表示獲取鎖失敗後直接返回而不再等待;另一個重要引數的$expire,這個引數指當前鎖的最大生存時間,以秒為單位的,它必須大於0,如果超過生存時間鎖仍未被釋放,則系統會自動強制釋放。這個引數的最要作用請看上面的(1)裡的解釋。

  這裡先取得當前時間,然後再獲取到鎖失敗時的等待超時的時刻(是個時間戳),再獲取到鎖的最大生存時刻是多少。這裡redis的key用這種格式:”Lock:鎖的標識名”,這裡就開始進入迴圈了,先是插入資料到redis裡,使用setnx()函式,這函式的意思是,如果該鍵不存在則插入資料,將最大生存時刻作為值儲存,假如插入成功,則對該鍵進行失效時間的設定,並將該鍵放在$lockedName陣列裡,返回true,也就是上鎖成功;如果該鍵存在,則不會插入操作了,這裡有一步嚴謹的操作,那就是取得當前鍵的剩餘時間,假如這個時間小於0,表示key上沒有設定生存時間(key是不會不存在的,因為前面setnx會自動建立)如果出現這種狀況,那就是程式的某個例項setnx成功後 crash 導致緊跟著的expire沒有被呼叫,這時可以直接設定expire並把鎖納為己用。如果沒設定鎖失敗的等待時間 或者 已超過最大等待時間了,那就退出迴圈,反之則 隔 $waitIntervalUs 後繼續 請求。  這就是加鎖的整一個程式碼分析。

接著看解鎖的程式碼分析:解鎖就簡單多了,傳入引數就是鎖標識,先是判斷是否存在該鎖,存在的話,就從redis裡面通過deleteKey()函式刪除掉鎖標識即可。

在貼上刪除掉所有鎖的方法,其實都一個樣,多了個迴圈遍歷而已。

以上就是用Redis實現分散式鎖的整一套思路和程式碼實現的總結和分享,這裡我附上正一個實現類的程式碼,程式碼裡我基本上對每一行進行了註釋,方便大家快速看懂並且能模擬應用。想要深入瞭解的請看整個類的程式碼:

 

(二)用Redis實現任務佇列的程式碼分析

  (1)任務佇列,用於將業務邏輯中可以非同步處理的操作放入佇列中,在其他執行緒中處理後出隊

  (2)佇列中使用了分散式鎖和其他邏輯,保證入隊和出隊的一致性

  (3)這個佇列和普通佇列不一樣,入隊時的id是用來區分重複入隊的,佇列裡面只會有一條記錄,同一個id後入的覆蓋前入的,而不是追加, 如果需求要求重複入隊當做不用的任務,請使用不同的id區分

  先看入隊的程式碼分析:首先當然是對引數的合法性檢測,接著就用到上面加鎖機制的內容了,就是開始加鎖,入隊時我這裡選擇當前時間戳作為score,接著就是入隊了,使用的是zset資料結構的add()方法,入隊完成後,就對該任務解鎖,即完成了一個入隊的操作。

 

接著來看一下出隊的程式碼分析:出隊一個Task,需要指定它的$id 和 $score,如果$score與佇列中的匹配則出隊,否則認為該Task已被重新入隊過,當前操作按失敗處理。首先和對引數進行合法性檢測,接著又用到加鎖的功能了,然後及時出隊了,先使用getScore()從Redis裡獲取到該id的score,然後將傳入的$score和Redis裡儲存的score進行對比,如果兩者相等就進行出隊操作,也就是使用zset裡的delete()方法刪掉該任務id,最後當前就是解鎖了。這就是出隊的程式碼分析。

學過資料結構這門課的朋友都應該知道,佇列操作還有彈出頂部某個值的方法等等,這裡處理入隊出隊操作,我還實現了 獲取佇列頂部若干個Task 並將其出隊的方法,想了解的朋友可以看這段程式碼,假如看不太明白就留言,這裡我不再對其進行分析了。

以上就是用Redis實現任務佇列的整一套思路和程式碼實現的總結和分享,這裡我附上正一個實現類的程式碼,程式碼裡我基本上對每一行進行了註釋,方便大家快速看懂並且能模擬應用。想要深入瞭解的請看整個類的程式碼:

  到此,這兩大塊功能基本講解完畢,對於任務佇列,你可以寫一個shell指令碼,讓伺服器定時執行某些程式,實現入隊出隊等操作,這裡我就不在將其與實際應用結合起來去實現了,大家理解好這兩大功能的實現思路即可,由於程式碼用的是PHP語言來寫的,如果你理解了實現思路,你完全可以使用java或者是.net等等其他語言去實現這兩個功能。這兩大功能的應用場景十分多,特別是秒殺,另一個就是春運搶火車票,這兩個是最鮮明的例子了。當然還有很多地方用到,這裡我不再一一列舉。 

  好了,本次總結和分享到此完畢。最後我附上 分散式鎖和任務佇列這兩個類:

相關文章