Redis publish-subscribe:即使在巨大的压力下，Redis也能保证传递消息吗？

Question

如果订阅的客户端和发布消息的服务器都保持连接，那么Redis是否保证即使在客户端和/或服务器压力很大的情况下，最终也会始终将发布的消息传递给订阅的客户端？或者我应该考虑到这样一种可能性，Redis可能会在事情变得“热门”时偶尔丢弃消息？

Answer 1

Redis绝对不会为发布和订阅流量提供任何有保证的交付。此机制仅基于套接字和事件循环，不涉及队列(即使在内存中)。如果发布发生时订阅服务器没有侦听，则此订阅服务器的事件将丢失。

可以在Redis之上实现一些有保证的交付机制，但不能使用发布和订阅API。Redis中的列表数据类型可以用作队列，也可以作为更高级排队系统的基础，但它不提供多播功能(因此没有发布和订阅)。

AFAIK，没有明显的方法可以轻松地实现发布-订阅和保证交付的同时与Redis。

Answer 2

Redis不使用其发布/订阅机制提供有保证的交付。此外，如果订阅者没有在通道上主动侦听，它将不会接收本应发布的消息。

我之前写过一篇详细的文章，描述了如何结合使用Redis列表和BLPOP来实现可靠的多播发布/订阅交付：

http://blog.radiant3.ca/2013/01/03/reliable-delivery-message-queues-with-redis/

为了记录在案，这里是高级策略：

• 当每个使用者启动并准备使用消息时，它通过将自己添加到表示队列中注册的所有使用者的集合中进行注册。
• 当生产者在队列上发布消息时，它：
  • 将消息的内容保存在Redis键中
  • 遍历队列中注册的一组使用者，并将消息ID推送到每个已注册的Redis的列表中

​

• 每个消费者不断地在其特定于消费者的列表中寻找新的条目，当有新条目出现时，删除该条目(使用BLPOP操作)，处理该消息并转到下一条消息。

我还开源地提供了这些原则的Java实现：https://github.com/davidmarquis/redisq

这些原则已经用于每秒处理来自单个Redis实例和消费者应用程序的两个实例的大约1000条消息，每个实例使用5个线程的消息。