在程序員這個圈子打拼了太多年，見過太多的程序員使用redis，其中一部分喜歡把redis做緩存（cache）使用，其中最典型的當(dāng)屬存儲用戶session，除此之外，把redis作為消息隊(duì)列使用也不在少數(shù)，可見redis在互聯(lián)網(wǎng)中應(yīng)用是多么的廣泛。

redis作為消息隊(duì)列使用，redis支持的數(shù)據(jù)結(jié)構(gòu)是可以支撐這類業(yè)務(wù)，主要是利用了list這種數(shù)據(jù)結(jié)構(gòu)的特性。Redis的列表相當(dāng)于編程語言里面的 LinkedList，是一個雙向的列表結(jié)構(gòu)，這意味著列表新增和刪除元素是非?？斓?，時(shí)間復(fù)雜度為O(1)，但是查找一個元素的時(shí)候需要遍歷列表，時(shí)間復(fù)雜度為O(n)。由于列表的元素操作和消息隊(duì)列操作類似，所以redis可以適用于消息隊(duì)列的場景，當(dāng)然，在適用于的棧的場景下也可以勝任。

列表這種數(shù)據(jù)結(jié)構(gòu)的命令為

消息隊(duì)列的本質(zhì)還是消費(fèi)者和生產(chǎn)者的問題，只要是這樣的場景，就會涉及到兩端不平衡的情況，具體可表現(xiàn)為：

1. 生產(chǎn)者生產(chǎn)速度大于消費(fèi)者消費(fèi)速度，面臨消息不斷堆積的問題，隨著消息數(shù)據(jù)的堆積，隊(duì)列是開啟限流措施，還是丟棄某些消息，更或者是把消息數(shù)據(jù)進(jìn)行持久化。對于基于redis實(shí)現(xiàn)的消息隊(duì)列，一般為可忍受部分消息丟失的業(yè)務(wù)，所以很多人選擇丟棄消息的方案。另一種方案是基于redis單線程機(jī)制，可以增加消費(fèi)者數(shù)量，這也是僅僅針對消息只被消費(fèi)一次的場景。當(dāng)然也可以選擇持久化方案，但是會對redis的性能產(chǎn)生影響。

2. 消費(fèi)者消費(fèi)速度大于生產(chǎn)者生產(chǎn)速度，有的同學(xué)會說，這樣挺好啊，是，在某種意義上是比反過來的那個場景要好一些，畢竟可以避免產(chǎn)生消息的堆積問題。但是消費(fèi)者沒有消息消費(fèi)，會導(dǎo)致消費(fèi)者進(jìn)程一直在那里浪費(fèi)cpu資源，而且還會把redis的QPS拉高。類似于這種死循環(huán)的場景，一般而且最常用的解決方案是讓線程sleep 一小段時(shí)間，既降低了消費(fèi)端cpu也降低了redis的QPS。但是sleep會有一個問題，會導(dǎo)致處理消息的延遲，例如sleep了一秒，那消息的延遲處理就有可能會延遲一秒，雖然在大部分場景下這都不是什么問題，但是作為程序員怎么能不追求極致和完美呢？

關(guān)于消息延遲的問題，最暴力簡單的方式就是增加消費(fèi)客戶端，這樣可用多消費(fèi)端交錯的方式來縮小延遲的間隔，當(dāng)然redis的設(shè)計(jì)者也考慮了這個問題，所有有了Blpop 命令

而且還可以設(shè)置超時(shí)自動返回，豈不是完美。但是還要順便一句，redis的連接在空閑一段時(shí)間后，服務(wù)端可能會主動斷開，Blpop命令會拋出異常，所以還要做好了重試或者其他策略為好。

3. 如果作為專業(yè)的消息隊(duì)列，一個消息被多個不同的業(yè)務(wù)消費(fèi)（一個消息被消費(fèi)多次）是必須要支持的，但是redis是基于自己的list數(shù)據(jù)結(jié)構(gòu)來實(shí)現(xiàn)的偽隊(duì)列，所以這種業(yè)務(wù)場景下就不要考慮redis了，或者自己封裝一個類似分發(fā)器的中間件也可以。

4. 基于redis的消息隊(duì)列沒有Ack的保證，換句話說，一個消息是否被正常處理redis是不知道的，這在很大程度上限制了它的適用場景。

我還是建議不要用redis做專業(yè)的MQ使用，畢竟MQ這種場景不是redis的設(shè)計(jì)初衷，但是太多人把redis做MQ使用，于是redis的作者基于redis的核心代碼實(shí)現(xiàn)了一個消息隊(duì)列：disque，也許未來會作為redis的核心組件,地址為 https://github.com/antirez/disque

除了disque，Redis Stream也是一個把redis作為MQ的比較好的解決方案，有興趣的同學(xué)可以研究一下。