具有可靠性的 Redis Pub/Sub

Question

我一直在考虑使用 Redis Pub/Sub 来替代 RabbitMQ。

根据我的理解，Redis 的发布/订阅与每个订阅者保持着持久连接，如果连接终止，所有 future 的消息都将丢失并掉落在地板上。

一个可能的解决方案是使用列表(和阻塞等待)来存储所有消息和发布/订阅，仅作为通知机制。我认为这让我完成了大部分工作，但我仍然对失败案例有些担忧。

1. 当订阅者死亡并重新上线时会发生什么，它应该如何处理所有待处理的消息？
2. 当系统收到格式错误的消息时，您如何处理这些异常？死信队列？
3. 是否有实现重试政策的标准做法？

Answer 1

当订阅者(消费者)死亡时，您的列表将继续增长，直到客户返回。一旦达到特定限制，您的生产者可以(从任一侧)修剪列表，但这是您需要在应用程序级别处理的事情。如果您在每条消息中包含一个时间戳，您的消费者就可以根据消息的年龄采取行动，假设您有应用程序逻辑要对消息年龄强制执行。

我不确定格式错误的消息将如何进入系统，因为与 Redis 的连接通常是具有完整性保证的 TCP。但如果发生这种情况，可能是由于生产者层的消息编码错误，您可以通过保持接收消费者异常消息的每个生产者队列来提供一种处理错误的通用机制。

重试策略在很大程度上取决于您的应用程序需求。如果您需要 100% 确保消息已被接收和处理，那么您应该考虑使用 Redis 事务(MULTI/EXEC)来包装消费者完成的工作，这样您就可以确保客户端不会删除消息，除非它已经完成了它的工作。如果您需要显式确认，则可以在专用于生产者进程的队列上使用显式 ACK 消息。

如果不进一步了解您的应用需求，就很难知道如何做出明智的选择。通常，如果您的消息需要完全的 ACID 保护，那么您可能还需要使用 redis 事务。如果您的消息仅在及时时才有意义，那么可能不需要交易。听起来好像您不能容忍丢失的消息，因此您使用列表的方法很好。如果您需要为您的消息实现一个优先级队列，您可以使用排序集(Z 命令)来存储您的消息，使用它们的优先级作为分值，以及轮询消费者。