Redis消息队列：RPOPLPUSH vs Pub/Sub

介绍

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 个队列：主队列、工作队列、拒绝队列。此外，每个消费者都有自己的工作队列。当查看队列列表时，有点错综复杂。

欢迎关注我的公众号：曲翎风，获得独家整理的学习资源和日常干货推送。
如果您对我的专题内容感兴趣，也可以关注我的博客：blog.qulingfeng.com