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