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