Rabbitmq - Разработка сервиса воспроизведения сообщений

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

  1. Создайте службу записи, которая будет:

    • Create a queue and bind all routing keys to it.
    • Потребляйте все сообщения от обмена.
    • Сохраните все сообщения в БД.

  2. Запрос подписчика на повтор.

    • Each subscriber creates a new exchange, queue and binds to it with same bindings as its regular queue.
    • Подписчик отправляет на веб-сервер запросы на отдых, чтобы начать воспроизведение с фильтром (дата начала и т. Д.). Запрос содержит название обмена воспроизведением.
    • Веб-сервер извлекает данные из БД и публикует их для конкретной биржи.
    • могут быть добавлены уточнения, такие как прикрепление RequestId и его повторное отображение.

введите описание изображения здесь

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

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

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

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

rabbitmq message-queue replay
person Bick    schedule 15.04.2015    source источник
comment
Весь вопрос выглядит довольно основанным на мнении, хотя без каких-либо конкретных требований сложно ответить ни на один из ваших подвопросов. Должно ли ваше приложение работать в реальном времени? Какую проблему решает очередь? Вам нужны очереди? Вам нужен доступ к сообщениям внутри очереди (очереди с произвольным доступом)?   -  person pinepain    schedule 15.04.2015
comment
Rabbitmq - не лучшее решение для этого imho. Считали ли вы за это Кафку?   -  person sotn    schedule 01.09.2018

Ответы (2)


arrow_upward
8
arrow_downward

  1. Имеет ли это смысл?

да

  1. Я изобретаю колесо? Есть ли решение, присущее кролику? плагин?

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

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

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

Вы можете взглянуть на пожарный шланг.

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

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

Вы также можете взглянуть на шаблон прямой ответ.

  1. Считается ли создание нескольких бирж хорошей практикой?

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

person Nicolas Labrot    schedule 15.04.2015

arrow_upward
2
arrow_downward

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

Этот обмен специфичен для 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/

person Simrandeep Singh    schedule 20.09.2015