redis以內存數據庫而聞名。但是，某些系統將它用作消息隊列管理工具。
Pub/Sub 和 RPOPLPUSH 是用于實現這樣一個系統的兩組命令。在這篇文章中，我將分享一些關于這兩個命令集的知識，它們的用例以及優缺點。
PUBLISH/SUBSCRIBE
假設 Pub/Sub 就像一個無線電臺，所有訂閱隊列的使用者都將接收發布到該隊列的所有消息。
它是如何工作的
消費者 C1、C2、C3 訂閱隊列 q
生產者 P 將消息m發布到隊列 q
隊列 q 向所有消費者 C1、C2、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。
消費者 C2、C3 依次處理與 C1 相同的流中的消息，但處理的消息不同。只有一個使用者成功地使用了一個特定的消息。
例子
這種機制在一個消息被一個且只有一個消費者成功消費的情況下非常有用。
什么時候不使用
此過程至少創建 3 個隊列：主隊列、工作隊列、拒絕隊列。此外，每個消費者都有自己的工作隊列。當查看隊列列表時，有點錯綜復雜。
