Rabbitmq-设计消息重播服务

Question

我正在尝试设计一种重播机制,使用户能够重放队列中的消息.我为包含多个队列和多个消费者的交换而设计的最佳设计是:

1. 创建一个记录器服务,它将:

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

2. 订阅者请求重播.

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

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

另一种解决方案:
1.为每个队列创建一个额外的队列"ReplayQueue".设置一个TTL(假设一个月).
2.每次用户请求重播时,让他从自己的ReplayQueue重放,而不需要进行重放.

这个解决方案有点问题,因为.

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

Answer 1

1. 那有意义吗？

是

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

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

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

您将有一个队列（STORE），所有已发布的消息都应路由到该队列。STORE您可以考虑使用主题交换，而不是使用所有绑定键进行绑定。. # *路由消息时，绑定密钥必须不包含价格，并且会产生一些开销。该STORE队列将绑定密钥绑定#。

你可以看看firehose。

为什么要进行网络请求？您不能将Rabbit与RPC调用一起使用：

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

您也可以看看直接回复模式。

3. 创建多个交易所是否被视为一种好习惯？

是的，只要您需要它。对于您的特定情况，我认为无需按用户交换。该请求已包含队列名称。您可以使用默认交换简单地发布到此队列amq.direct，并且路由键等于队列名称。如果您想进行交换，则可以创建一个唯一的交换（例如“重播”）。每个订户将其重播队列绑定到此交换。“重播”交换可以是约定的，也可以与请求一起发送。