Rabbitmq - 设计消息重放服务答案

【问题标题】：Rabbitmq- Designing a message replay serviceRabbitmq - 设计消息重放服务
【发布时间】：2015-06-21 03:43:22
【问题描述】：

我正在尝试设计一种重播机制，使用户能够重播队列中的消息。对于包含多个队列和多个消费者的交换，我提出的最佳设计是：

创建一个记录器服务，它将：
- 创建一个队列并将所有路由键绑定到它。
- 使用来自交换的所有消息。
- 将所有消息保存到数据库。
订阅者请求重播。
- 每个订阅者创建一个新的交换、队列并使用与其常规队列相同的绑定绑定到它。
- 订阅者向 Web 服务器发送休息请求以使用过滤器（开始日期等）开始重播。请求包含其重播交换名称。
- Web 服务器从数据库中提取数据并将其发布到特定的交换器
- 可以添加改进，例如附加 RequestId 并将其回显。

问题：
1. 这有意义吗？
2. 我在发明轮子吗？有兔子固有的解决方案吗？插件？
3. 创建多个交易所是否被认为是一种好的做法？
在这个解决方案中，为每个队列创建了一个交换，以便发布相同的消息。

另一种解决方案：
1. 为每个队列创建一个附加队列“ReplayQueue”。设置一个 TTL（假设是一个月）。
2. 每次用户请求重放时，让他从自己的 ReplayQueue 中重放而不需要确认。

这个解决方案有点问题，因为。

为了重播最后一天，消费者必须获取之前的所有 29 天并将它们过滤掉。
此解决方案可扩展 - 队列将变得更大（与可以扩展的数据库存储不同）。

【问题讨论】：

整个问题看起来非常基于意见，但没有任何具体要求，很难回答您的任何子问题。你的应用应该是实时的吗？队列解决了什么问题？你需要排队吗？您是否需要访问队列中的消息（随机访问队列）？
Rabbitmq 不是这个恕我直言的最佳解决方案。你考虑过 Kafka 吗？

标签： rabbitmq message-queue replay

【解决方案1】：

这有意义吗？

是的

我是在发明轮子吗？有兔子固有的解决方案吗？插件？

您不是在重新发明轮子。 AFAIK 没有兔子解决方案，也没有开箱即用的解决方案。

我认为您的第一个解决方案很好。 Another solution 非常有问题，因为健康的兔子是空的，而兔子不是数据存储。

您将拥有一个队列 (STORE)，所有已发布的消息都应路由到该队列。您可以考虑使用主题交换，而不是将STORE 与所有绑定键绑定。代价是绑定密钥不能包含. # * 和路由消息时的轻微开销。 STORE 队列将与绑定键 # 绑定。

你可以看看firehose。

为什么是网络请求？您可以将 Rabbit 与 RPC call 一起使用：

订阅者发送 amqp 请求以使用过滤器（开始日期等）开始重播。
请求包含reply-to 队列名称。队列可能对客户端和请求是独占的。
RPC 服务器从数据库中提取数据并将其发布到回复队列

您还可以查看direct-reply-to 模式。

创建多个交易所是否被认为是一种好的做法？

是的，只要您需要。对于您的具体情况，我认为没有必要为每个订户进行交换。该请求已包含队列名称。您可以简单地使用默认交换 amq.direct 发布到此队列，路由键等于队列名称。如果你想要一个交换，我会创建一个唯一的交换（例如“重播”）并让每个订阅者将他们的重播队列绑定到这个交换。 “重播”交换可以是约定或随请求一起发送。

【讨论】：

【解决方案2】：

第一种方案是可行的。鉴于 rabbit MQ 附带 tracing plugin，将消息存储在 DB 中变得更加容易，因为它简单地归结为从绑定到 amq.rabbitmq.trace 交换的队列中消费。

此交换特定于vhost，每个虚拟主机都有自己的amq.rabbitmq.trace 交换。此外，在创建新跟踪时，可以限制启用跟踪的队列/交换，从而灵活地在不需要的地方禁用跟踪。

请参考以下链接配置跟踪：
https://www.rabbitmq.com/firehose.html
https://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/

【讨论】：