Rabbitmq - 设计消息重放服务

Posted 2023-03-10

【中文标题】Rabbitmq - 设计消息重放服务

【英文标题】：Rabbitmq- Designing a message replay service

【发布时间】：2015-06-21 03:43:22

【问题描述】：

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

创建一个记录器服务，它将：

创建一个队列并将所有路由键绑定到它。 使用来自交换的所有消息。 将所有消息保存到数据库。

订阅者请求重播。

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

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

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

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

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

【问题讨论】：

整个问题看起来非常基于意见，但没有任何具体要求，很难回答您的任何子问题。你的应用应该是实时的吗？队列解决了什么问题？你需要排队吗？您是否需要访问队列中的消息（随机访问队列）？

Rabbitmq 不是这个恕我直言的最佳解决方案。你考虑过 Kafka 吗？

【参考方案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.htmlhttps://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/