總結

目前使用redis做消息隊列的的方式有3中，list,? ? ??publish/subscribe,? ? ? ?stream

list做mq的總結

使用方法

1. 生產者可以 lpush 寫入消息，消費者可以 rpop 讀取消息，也就是pull模式

2. 消費者可以使用 brpop 阻塞性讀取消息，約等于服務器端的實時推送

3. 如何保證消息讀取但未處理時，消費者程序異常宕機造成的消息丟失，答案：rpoplpush 或 brpoplpush ，即先從原隊列中移除一個消息并插入到一個新隊列，消費者處理完該消息后再從新隊列中刪除，相當于ack機制，避免消費者異常時消息丟失

缺點

1.一個消息只能被消費一次，缺乏廣播機制

缺點舉例：游戲開發中，玩家登陸時，很多進程需要監聽該登陸消息做對應的處理，但是因為list消息只能被消費一次，無法滿足需求（雖然你可以為登陸事件搞多個list，每個關心登陸事件的進程監聽一個list，登陸時也把一個消息壓入多個list，只是生產者消費者太過耦合）

publish/subscribe

使用方法

1. 生產者可以 publish 寫入消息，消費者可以 subscribe 監聽消息，也就是push模式

2. 多個消費者可以 subscribe 同一個消息，消費者publist后，所有的消費者都能收到通知，以此解決了list中一個消息只能被消費一次的缺點

3. 可以使用通配符*進行簡單的正則匹配，比如多個類似channel（廣東深圳頻道，廣東廣州頻道，廣東東莞頻道）這個時候消費者可以 subscribe 廣東*頻道 來監聽所有這樣的頻道

缺點

1. 解決了list做mq時消息不能廣播的問題

2. 服務器是即時推送，不保存消息，所以消費者一旦斷線，消息就丟失了

3. 消息無堆積，不能削峰填谷。因為服務器不考慮消費者，只按照生產者的速度推送。若消費者速度慢，消息就會在client連接的buf中堆積，超過閥值后會斷開連接，這樣消息就全部丟失了

stream

使用方法

具體使用過可參考筆者的這篇博客

redis 流 stream的使用總結 - 基礎命令_YZF_Kevin的博客-CSDN博客_redis 流

優點

1. 完全對標kafka的模型重新設計的全內存的mq，速度高于kafka

2. pull模式，且有ack機制。且數據也會隨著持久化保存在rdb和aof文件中，即使redis重啟，保證數據不會丟失

3. 有消費者組的概念，一個topic可以有多個消費者組，一個消費者組內可以有多個消費者，既支持消息廣播（一條msg能被多個不同的消費者組重復消費），又可以水平擴展（一個消費者組內增加多個消費者依次增加處理速度）

缺點

1. 完全用內存做消息堆積，相比那些以硬盤做堆積的，成本較高

2. redis存在數據丟失的可能性（單點redis持久化時everysec也可能會丟失一秒的數據；集群redis的主從同步也可能會丟失數據）

總結

以上是生活随笔為你收集整理的使用redis做消息队列mq的总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。