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