Redis进阶-Redis 4种MQ 方案对比
文章目錄
- Pre
- 方案1 Pub/Sub
- 優點
- 缺點
- 小結
- 方案2 List
- 優點
- 缺點
- 小結
- 方案3 ZSet
- 優點
- 缺點
- 小結
- 方案4 stream
Pre
最終方案-----> Redis進階-Stream多播的可持久化的消息隊列
我們知道redis 5.x版本，作者提供了stream這種基于radix tree 基數樹的數據結構，解決使用Redis實現MQ“百花齊放”的亂象。
這里我們來聊一聊使用Redis實現MQ的主要集中實現以及利弊
方案1 Pub/Sub
Redis-13Redis發布訂閱
優點
缺點
消息沒有持久化的機制。當消費者的連接斷掉 后，再次重連，那么Channel中的消息對于該消費者而言將無法消費。
消費消息的速度和消費者的數量成反比. 當消費者的數量達到一定規模時，服務器的性能將線性下降，因此每個消費者獲取到消息的延遲也線性增長
當生產者產生消息的速度遠大于消費者的消費能力的時候，消費者會被強制斷開連接，因此會造成消息的丟失
client-output-buffer-limit pubsub 32mb 8mb 60
當消費者的buffer積壓超過32MB，或者在60s內消費者的buffer一直保持在8MB以上，那么該消費者就會被redis服務器給強制斷開連接，可以修改這個配置，但無法預料修改后的會帶來什么樣的結果。
小結
Redis的Pub/Sub模型對于無法容忍數據丟失，消息可能積壓的場景不太適合。
方案2 List
Redis進階-List底層數據結構精講
優點
消息可以持久化。當consumer斷開連接或者crash的時候，再次去消費，歷史消息會得以保留，可以從最后一次消費的位置進行消費
消息可以積壓。當生產者產生消息的速度大于消費者的速度的時候，除了會耗費一些內存外，無其他影響
缺點
小結
List方案適合應用在消息最多被消費一次的場景 .
如果想要消息被重復消費，需要通過其他手段來解決，比如
-
一個消費者消費完消息之后，把它加入到另外一個隊列的對尾，其他消費者從這個新建的隊列中消費消息，這樣就會造成多個消費者消費的順序依賴，不能并行執行
-
在消費者消費之前，對消息進行處理，把該消息寫入到若干個隊列中，這樣能支持多個消費者同時消費，但是數據卻被拷貝了多次
方案3 ZSet
優點
在5.0的stream出現之前，zset是這幾種之中最復雜的實現方案，但是它能有效地解決Pub/Sub和List方案的不足。
-
ZSet支持消息持久化
-
ZSet支持消息重復消費。 ZSet使用的獲取消息操作ZRANGEBYSCORE（返回有序集合中指定分數區間的成員列表） ，該操作不會刪除消息
缺點
使用zset要考慮一下幾點
- 消息的順序。 score至關重要，這關系到消息的先后順序，比如使用timestamp+seq作為score能夠保證消息的順序。
- 重復消息的添加。zset重復的消息是不能夠添加到集合中的， 當消息一樣的時候，如何存放，需要考慮
小結
基于上述原因 ZSet方案的實現相比list和pub/sub 相對復雜。
方案4 stream
千呼萬喚始出來， stream解決你的絕大部分苦惱 ~
Redis進階-Stream多播的可持久化的消息隊列
總結
以上是生活随笔為你收集整理的Redis进阶-Redis 4种MQ 方案对比的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Redis进阶-Stream多播的可持久
- 下一篇： Redis进阶-Redis持久化原理