Redis消息隊列：RPOPLPUSH vs Pub/Sub

介紹

Redis之內存數據庫而聞名。可是，某些系統將它用做消息隊列管理工具。
Pub/Sub 和 RPOPLPUSH 是用於實現這樣一個系統的兩組命令。在這篇文章中，我將分享一些關於這兩個命令集的知識，它們的用例以及優缺點。

PUBLISH/SUBSCRIBE

假設 Pub/Sub 就像一個無線電臺，全部訂閱隊列的使用者都將接收發布到該隊列的全部消息。

它是如何工做的

消費者 C一、C二、C3 訂閱隊列 q
生產者 P 將消息m發佈到隊列 q
隊列 q 向全部消費者 C一、C二、C3 發送消息

例子

羣聊系統是這種消息隊列類型的典型例子，其中用戶向一個組發送消息，全部其餘組成員都須要接收該消息。Pub/Sub 是一個很好的工具，能夠確保消息傳遞給全部訂閱者。

何時不使用

因爲內存緩衝區的效率，若是消費者失去了與隊列的鏈接，那麼消費者頗有可能在鏈接丟失時丟失消息。Redis服務器決定清除消息緩衝區，爲下一個傳入的消息節省更多的內存。

RPOPLPUSH

RPOPLPUSH(可靠隊列模式)的工做方式不一樣。消息隊列管理的實現來自客戶機，而不是Redis服務器。

它是如何工做的

隊列 q 是 Redis 中的一個列表。
生產者 P LPUSH 消息 m1, m2, m3 到列表 q。
消費者 C1 經過使用命令 RPOPLPUSH 從列表 q 中彈出消息 m1 來消費來自列表 q 的消息，同時將該消息推送到另外一個工做列表 q-c1-working。
若是 C1 成功使用 m1，它會將消息 m1 從工做列表 q-c1-working 中刪除。
若是 C1 未能使用該消息，根據業務邏輯，它將：消息 m1 從新排隊到原始隊列 q 或者拒絕消息 m1，將其移動到拒絕隊列 q-rejected。
消費者 C二、C3 依次處理與 C1 相同的流中的消息，但處理的消息不一樣。只有一個使用者成功地使用了一個特定的消息。

例子

這種機制在一個消息被一個且只有一個消費者成功消費的狀況下很是有用。

何時不使用

此過程至少建立 3 個隊列：主隊列、工做隊列、拒絕隊列。此外，每一個消費者都有本身的工做隊列。當查看隊列列表時，有點錯綜複雜。

歡迎關注個人公衆號： 曲翎風，得到獨家整理的學習資源和平常乾貨推送。
若是您對個人專題內容感興趣，也能夠關注個人博客： blog.qulingfeng.com