rabbitmq - Rabbitmq-设计消息重播服务

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

创建一个记录器服务，该服务将:

创建一个队列并将所有路由键绑定(bind)到该队列。

消耗来自交换的所有消息。

将所有消息保存到数据库。

订户重播请求。

每个订户创建一个新的交换，队列，并以与常规队列相同的绑定(bind)绑定(bind)到它。

订阅服务器将休息请求发送到Web服务器，以使用过滤器(startdate等)开始重播。请求包含其重播交换名称。

Web服务器从数据库中提取数据并将其发布到特定的交易所

可以添加

改进，例如附加RequestId并将其回显。

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

另一个解决方案:
1.为每个队列创建一个附加队列“ReplayQueue”。设置一个TTL(假设一个月)。
2.每次用户请求重播时，请他从其自己的ReplayQueue中重播，而不进行确认。

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

为了在最后一天重播，消费者将必须提取所有早29天并将其过滤掉。

此解决方案可以扩展-队列将变得更大(与可以扩展的数据库存储不同)。

最佳答案

是



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

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

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

您可以看看firehose。

为什么要进行网络请求？您可以将Rabbit与RPC call一起使用:

订阅服务器发送一个amqp请求，以使用过滤器(startdate等)开始重播。

请求包含reply-to队列名称。队列可以是客户端和请求所独有的。

RPC服务器从数据库中提取数据并将其发布到答复队列

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



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