Redis发布 - 订阅：Redis是否保证即使在巨大压力下也能传递消息？

Question

如果订阅的客户端和发布消息的服务器都保留连接，Redis保证始终将发布的消息最终传递给订阅的客户端，即使在客户端和/或服务器受到巨大压力的情况下也是如此？或者我应该计划Redis可能会在事情变得“热”的时候偶尔丢弃消息吗？

Answer 1

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

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

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

Answer 2

Redis不使用其Pub / Sub机制提供有保证的传递。此外，如果订户没有主动收听频道，它将不会收到已发布的消息。

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

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

为了记录，这是高级别战略：

• 当每个消费者启动并准备消费消息时，它会通过将自身添加到代表队列中注册的所有消费者的集合来进行注册。
• 当生产者在队列上发布消息时，它：
  • 以Redis密钥保存邮件内容
  • 对队列中注册的消费者集进行迭代，并在列表中为每个已注册的消费者推送消息ID
• 每个消费者在其特定于消费者的列表中不断寻找新条目，当有人进入时，删除条目（使用BLPOP操作），处理消息并转到下一条消息。 / LI>

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

这些原则已用于从单个Redis实例和消费者应用程序的两个实例每秒处理大约1,000条消息，每个实例消耗5个线程的消息。