Rabbitmq- Проектирование службы воспроизведения сообщений

Я пытаюсь создать механизм повтора, который позволит пользователям воспроизводить сообщения из очередей. Лучший дизайн, который я придумал для обмена, который содержит несколько очередей и нескольких потребителей:

Создайте службу рекордера, которая будет:
- Создайте очередь и привяжите к ней все ключи маршрутизации.
- Потребляйте все сообщения из обмена.
- Сохранить все сообщения в БД.
Запрос подписчика на повтор.
- Каждый абонент создает новый обмен, очередь и привязывается к нему с теми же привязками, что и его очередная очередь.
- Абонент отправляет запросы на отдых на веб-сервер, чтобы начать воспроизведение с помощью фильтра (startdate и т.д.). Запрос содержит имя для обмена воспроизведением.
- Веб-сервер извлекает данные из БД и публикует их для конкретного обмена.
- уточнения могут быть добавлены как присоединение RequestId и повторение его обратно.

Вопросы:
1. Имеет ли это смысл?
2. Я изобретаю колесо? Есть ли решение для кроликов? плагин?
3. Является ли создание нескольких обменов хорошей практикой?
В этом решении для каждой очереди создается обмен для публикации того же сообщения.

Другое решение:
1. Создайте дополнительную очередь "ReplayQueue" для каждой очереди. установить TTL (допустим, месяц).
2. Каждый раз, когда пользователь запрашивает повтор, пусть он переигрывает из собственного ReplayQueue без выделения.

Это решение немного проблематично, потому что.

Чтобы воспроизвести последний день, потребители должны будут получить все предыдущие 29 дней и отфильтровать их.
Это решение масштабируется - очереди становятся больше (в отличие от хранилища db, которое может масштабироваться).

Ответ 1

Это имеет смысл?

Да

Я изобретаю колесо? Есть ли решение для кроликов? плагин?

Вы не изобретаете велосипед. В AFAIK нет решения для кроликов и нет готового решения.

Ваше первое решение, на мой взгляд, хорошее. Another solution очень проблематичен, потому что здоровый кролик - пустой, а кролик - не хранилище данных.

У вас будет очередь (STORE), в которую должны быть перенаправлены все опубликованные сообщения. Вместо привязки STORE со всеми связующими ключами вы можете рассмотреть возможность обмена темой. По цене, что ключ привязки не должен содержать . # * и небольшие накладные расходы при маршрутизации сообщения. Очередь STORE связывается с ключом привязки #.

Вы можете посмотреть firehose.

Почему веб-запрос? Вы не можете использовать Rabbit с вызовом RPC:

Абонент отправляет запрос amqp, чтобы начать воспроизведение с фильтра (startdate и т.д.).
Запрос содержит имя очереди reply-to. Очередь может быть исключительной для клиента и запроса.
Сервер RPC извлекает данные из БД и публикует его в очереди ответа

Вы также можете взглянуть на шаблон direct-reply-to.

Является ли создание нескольких обменов хорошей практикой?

Да, как только это вам понадобится. Для вашего конкретного случая, на мой взгляд, обмен на абонента не требуется. Запрос содержит уже имя очереди. Вы можете просто опубликовать эту очередь, используя обмен по умолчанию amq.direct с ключом маршрутизации, равным имени очереди. Если вы хотите обменять, я бы создал уникальный обмен (например, "replay" ). Каждый абонент связывает свои очереди воспроизведения с этим обменом. Обмен "повторением" может быть условным или отправляться с запросом.

Ответ 2

Первое решение возможно. Учитывая, что кролик MQ поставляется с tracing plugin, сохранение сообщения в БД становится еще более простым, поскольку оно просто сводится к потреблению из очереди, привязанной к обмену amq.rabbitmq.trace.

Этот обмен относится к vhost, и каждый vhost имеет свой собственный обмен amq.rabbitmq.trace. Кроме того, при создании новой трассировки можно ограничить, в какую очередь/обмен включить трассировку, тем самым предоставляя гибкость для отключения трассировки там, где это не требуется.

Для настройки трассировки см. следующие ссылки:
https://www.rabbitmq.com/firehose.html
https://www.rabbitmq.com/blog/2011/09/09/rabbitmq-tracing-a-ui-for-the-firehose/