0134 Web應用中的輕量級訊息佇列

2021-07-05 22:08:08 字數 1368 閱讀 1807

web應用中為什麼會需要訊息佇列?主要原因是由於在高併發環境下,由於來不及同步處理,請求往往會發生堵塞,比如說,大量的insert,update之類的請求同時到達mysql,直接導致無數的行鎖表鎖,甚至最後請求會堆積過多,從而觸發too many connections錯誤。通過使用訊息佇列,我們可以非同步處理請求,從而緩解系統的壓力。在web2.0的時代,高併發的情況越來越常見,從而使訊息佇列有成為居家必備的趨勢,相應的也湧現出了很多實現方案,像twitter以前就使用rabbitmq實現訊息佇列服務,現在又轉而使用kestrel來實現訊息佇列服務,此外還有很多其他的選擇,比如說:activemq,zeromq等。

上述訊息佇列的軟體中,大多為了實現amqp,stomp,xmpp之類的協議,變得極其重量級,但在很多web應用中的實際情況是:我們只是想找到乙個緩解高併發請求的解決方案,不需要雜七雜八的功能,乙個輕量級的訊息佇列實現方式才是我們真正需要的。

第一感覺是能不能使用memcached來實現訊息佇列?稍加考慮後就會發現它不合適,因為memcached僅僅支援鍵值方式的操作,沒有排序之類的功能,所以如果要用它來實現訊息佇列,則必須自己通過某個鍵來儲存陣列形式的佇列,不過這樣的話,在操作佇列的時候很容易丟失資料,比如說我們要新增乙個訊息,則需先取出現有佇列,然後把訊息儲存到佇列尾部,最後儲存佇列,單純使用memcached的話,由於我們無法保證整個過程的原子性,所以當處理若干個併發請求時,各個請求間可能會互相覆蓋,丟失資料就在所難免。另外,memcached只是記憶體鍵值快取而已,一旦宕機,資料就消失了。

memcacheq的出現解決了上面的問題,它在memcached的基礎上實現了訊息佇列,以php客戶端為例:

訊息從尾部入棧:memcache_set 

訊息從頭部出棧:memcache_get

memcacheq依附於memcached之上,所以你可以通過現有的memcached工具來操作它,這無疑是它的一大優勢,但它也有乙個很大的缺點,那就是memcacheq本身的開發維護似乎並不活躍,如果遇到問題的話,你很可能需要自己動手解決。

目前看來,我更推薦下面這種解決方案,那就是redis,如果不了解,可以參考我以前的文章,表面上看,redis和memcached差不多,也是鍵值操作,但是redis本身實現了list,相關操作也可以保證是原子的,所以可以很自然的通過list來實現訊息佇列:

訊息從尾部入棧:rpush 

訊息從頭部出棧:lpop

redis本身雖然是乙個新專案,但很有朝氣,開發維護也很活躍,如果你的下乙個web應用裡需要使用輕量級的訊息佇列,不妨使用它。

此外,還有不少其他的選擇可供嘗試,比如說mysql第三方的q4m引擎,通過擴充套件sql語法來操作訊息佇列,也是乙個不錯的選擇。

套用網路流行語:那些重量級軟體實現的不是你要的功能,而只是獨在高處不勝寒的寂寞,所以不必迷戀其中,它們只是傳說而已。

Web應用中的輕量級訊息佇列

web應用中為什麼會需要訊息佇列?主要原因是由於在高併發環境下,由於來不及同步處理,請求往往會發生堵塞,比如說,大量的insert,update之類的請求同時到達mysql,直接導致無數的行鎖表鎖,甚至最後請求會堆積過多,從而觸發too many connections錯誤。通過使用訊息佇列,我們可...

Web應用中的輕量級訊息佇列

web應用中為什麼會需要訊息佇列?主要原因是由於在高併發環境下,由於來不及同步處理,請求往往會發生堵塞,比如說,大量的insert,update之類的請求同時到達mysql,直接導致無數的行鎖表鎖,甚至最後請求會堆積過多,從而觸發too many connections錯誤。通過使用訊息佇列,我們可...

Web應用中的輕量級訊息佇列

web應用中為什麼會需要訊息佇列?主要原因是由於在高併發環境下,由於來不及同步處理,請求往往會發生堵塞,比如說,大量的insert,update之類的請求同時到達mysql,直接導致無數的行鎖表鎖,甚至最後請求會堆積過多,從而觸發too many connections錯誤。通過使用訊息佇列,我們可...