25

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

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

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

  2. 订阅者请求重播。

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

在此处输入图像描述

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

另一种解决方案：
1.为每个队列创建一个额外的队列“ReplayQueue”。设置一个 TTL（比如说一个月）。
2. 每次用户请求重播时，让他从自己的 ReplayQueue 中重播，无需确认。

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

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

2 回答 2

8
  1. 那有意义吗？

是的

  1. 我在发明轮子吗？有兔子固有的解决方案吗？插入？

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

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

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

你可以看看firehose。

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

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

您还可以查看直接回复模式。

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

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

于 2015-04-15T11:00:30.830 回答
2

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

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

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

于 2015-09-20T17:50:21.557 回答