Redis做消息隊列,香嗎?
來自:架構(gòu)師修行之路
菜菜哥,我剛做完了一個訂單系統(tǒng),感覺很簡單呀
說說看,大量的訂單狀態(tài)怎么處理的?
我設(shè)計的時候可是考慮了這一點,所以用了異步處理,采用了MQ
那用的什么MQ呢,透露一下唄
我用的redis做的MQ,很簡單,一天就寫完了
訂單那么重要的消息,我覺得用redis可能不適合哦!!
在程序員這個圈子打拼了太多年,見過太多的程序員使用redis,其中一部分喜歡把redis做緩存(cache)使用,其中最典型的當屬存儲用戶session,除此之外,把redis作為消息隊列使用也不在少數(shù),可見redis在互聯(lián)網(wǎng)中應(yīng)用是多么的廣泛。
redis作為消息隊列使用,redis支持的數(shù)據(jù)結(jié)構(gòu)是可以支撐這類業(yè)務(wù),主要是利用了list這種數(shù)據(jù)結(jié)構(gòu)的特性。Redis的列表相當于編程語言里面的 LinkedList,是一個雙向的列表結(jié)構(gòu),這意味著列表新增和刪除元素是非??斓?,時間復雜度為O(1),但是查找一個元素的時候需要遍歷列表,時間復雜度為O(n)。由于列表的元素操作和消息隊列操作類似,所以redis可以適用于消息隊列的場景,當然,在適用于的棧的場景下也可以勝任。
列表這種數(shù)據(jù)結(jié)構(gòu)的命令為
移出并獲取列表的第一個元素, 如果列表沒有元素會阻塞列表直到等待超時或發(fā)現(xiàn)可彈出元素為止。
BLPOP key1 [key2 ] timeout
移出并獲取列表的最后一個元素, 如果列表沒有元素會阻塞列表直到等待超時或發(fā)現(xiàn)可彈出元素為止。
BRPOP key1 [key2 ] timeout
從列表中彈出一個值,將彈出的元素插入到另外一個列表中并返回它;如果列表沒有元素會阻塞列表直到等待超時或發(fā)現(xiàn)可彈出元素為止。
BRPOPLPUSH source destination timeout
通過索引獲取列表中的元素
LINDEX key index
在列表的元素前或者后插入元素
LINSERT key BEFORE|AFTER pivot value
獲取列表長度
LLEN key
移出并獲取列表的第一個元素
LPOP key
將一個或多個值插入到列表頭部
LPUSH key value1 [value2]
將一個值插入到已存在的列表頭部
LPUSHX key value
獲取列表指定范圍內(nèi)的元素
LRANGE key start stop
移除列表元素
LREM key count value
通過索引設(shè)置列表元素的值
LSET key index value
對一個列表進行修剪(trim),就是說,讓列表只保留指定區(qū)間內(nèi)的元素,不在指定區(qū)間之內(nèi)的元素都將被刪除。
LTRIM key start stop
移除列表的最后一個元素,返回值為移除的元素。
RPOP key
移除列表的最后一個元素,并將該元素添加到另一個列表并返回
RPOPLPUSH source destination
在列表中添加一個或多個值
RPUSH key value1 [value2]
為已存在的列表添加值
RPUSHX key value
消息隊列的本質(zhì)還是消費者和生產(chǎn)者的問題,只要是這樣的場景,就會涉及到兩端不平衡的情況,具體可表現(xiàn)為:
1. 生產(chǎn)者生產(chǎn)速度大于消費者消費速度,面臨消息不斷堆積的問題,隨著消息數(shù)據(jù)的堆積,隊列是開啟限流措施,還是丟棄某些消息,更或者是把消息數(shù)據(jù)進行持久化。對于基于redis實現(xiàn)的消息隊列,一般為可忍受部分消息丟失的業(yè)務(wù),所以很多人選擇丟棄消息的方案。另一種方案是基于redis單線程機制,可以增加消費者數(shù)量,這也是僅僅針對消息只被消費一次的場景。當然也可以選擇持久化方案,但是會對redis的性能產(chǎn)生影響。
2. 消費者消費速度大于生產(chǎn)者生產(chǎn)速度,有的同學會說,這樣挺好啊,是,在某種意義上是比反過來的那個場景要好一些,畢竟可以避免產(chǎn)生消息的堆積問題。但是消費者沒有消息消費,會導致消費者進程一直在那里浪費cpu資源,而且還會把redis的QPS拉高。類似于這種死循環(huán)的場景,一般而且最常用的解決方案是讓線程sleep 一小段時間,既降低了消費端cpu也降低了redis的QPS。但是sleep會有一個問題,會導致處理消息的延遲,例如sleep了一秒,那消息的延遲處理就有可能會延遲一秒,雖然在大部分場景下這都不是什么問題,但是作為程序員怎么能不追求極致和完美呢?
關(guān)于消息延遲的問題,最暴力簡單的方式就是增加消費客戶端,這樣可用多消費端交錯的方式來縮小延遲的間隔,當然redis的設(shè)計者也考慮了這個問題,所有有了Blpop 命令
Redis Blpop 命令移出并獲取列表的第一個元素, 如果列表沒有元素會阻塞列表直到等待超時或發(fā)現(xiàn)可彈出元素為止。
redis 127.0.0.1:6379> BLPOP LIST1 LIST2 .. LISTN TIMEOUT
而且還可以設(shè)置超時自動返回,豈不是完美。但是還要順便一句,redis的連接在空閑一段時間后,服務(wù)端可能會主動斷開,Blpop命令會拋出異常,所以還要做好了重試或者其他策略為好。
3. 如果作為專業(yè)的消息隊列,一個消息被多個不同的業(yè)務(wù)消費(一個消息被消費多次)是必須要支持的,但是redis是基于自己的list數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)的偽隊列,所以這種業(yè)務(wù)場景下就不要考慮redis了,或者自己封裝一個類似分發(fā)器的中間件也可以。
4. 基于redis的消息隊列沒有Ack的保證,換句話說,一個消息是否被正常處理redis是不知道的,這在很大程度上限制了它的適用場景。
我還是建議不要用redis做專業(yè)的MQ使用,畢竟MQ這種場景不是redis的設(shè)計初衷,但是太多人把redis做MQ使用,于是redis的作者基于redis的核心代碼實現(xiàn)了一個消息隊列:disque,也許未來會作為redis的核心組件,地址為 https://github.com/antirez/disque
除了disque,Redis Stream也是一個把redis作為MQ的比較好的解決方案,有興趣的同學可以研究一下。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容,還沒關(guān)注的小伙伴,可以長按關(guān)注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內(nèi)容由21ic獲得授權(quán)后發(fā)布,版權(quán)歸原作者所有,本平臺僅提供信息存儲服務(wù)。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!