Rabbitmq-设计消息重播服务

Question

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

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

   • 创建一个队列并将所有路由键绑定到该队列。
   • 消费来自交易所的所有消息。
   • 将所有邮件保存到数据库。

2. 订阅者重播请求。

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



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

另一种解决方案：
1.创建一个额外的队列＆＃34; ReplayQueue＆＃34;对于每个队列。设置一个TTL（让我们说一个月） 2.每次用户请求重播时，让他从自己的ReplayQueue重放，而不需要进行重放。

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

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

Answer 1

  

  
1. 这有意义吗？
  

是

  

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

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

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

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

您可以查看firehose。

为什么要求网络？你不能使用带RPC call的兔子：

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

你也可以看看direct-reply-to模式。

  

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

是的，只要你需要它。对于您的具体情况，我认为不需要每个订户的交换。请求已包含队列名称。您可以使用默认交换amq.direct发布到此队列，路由密钥等于队列名称。如果你想要交换，我会创建一个独特的交易所（例如“重播”）。每个订户将其重播队列绑定到此交换。 “重播”交换可以是约定，也可以与请求一起发送。