Как сделать так, чтобы путь доставки в rabbitmq стал собственностью сообщения?

Question

Неверный вариант использования

Это типичный вариант использования pubsub: рассмотрим, что у нас есть M источников новостей, и есть N подписчиков, которые подписываются на нужные источники новостей и хотят получать обновления новостей. Тем не менее, мы хотим, чтобы эти обновления появлялись в mongodb - по сути, поддерживали самые последние обновления 'k' (их можно индексировать, искать и т.д.). Мы хотим спроектировать M для масштабирования до миллионов издателей, N - до нескольких миллионов.

Наконец, обновления подписчиков принимаются и хранятся на нескольких хостах и ​​их собственных mongodbs.

Моделирование в rabbitmq

Rabbitmq будет использоваться для сохранения сопоставлений (кто подписывается на какой источник новостей).

Я настроил систему pubsub следующим образом: мы создаем биржи издателей (каждый из которых связан с одним источником новостей) и типа fanout.

Для моделирующих подписчиков есть два варианта.

В первом варианте есть одна очередь для каждого подписчика, связанная с соответствующими издательскими биржами. И пусть клиент обрабатывает соединения со всеми этими очередями подписчиков и получает обновления (и сохраняет их в mongodb). Обратите внимание, что в этом варианте, когда клиент перезапускается, он должен управлять списком всех подписчиков и открывать соединения со всеми очередями подписчиков, за которые он отвечает.

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

Для достижения этой цели мы сначала создаем один обмен для каждого подписчика и позволяем ему привязываться к обмену издателей, которому он следует. Мы предоставляем отдельную очередь для каждого клиента и разрешаем обмену подписчиком привязываться к этой очереди (type = direct), если подписчик принадлежит этому клиенту.

Как только клиент получает сообщение об обновлении, он должен узнать, от какого абонентского обмена он пришел. Только тогда мы можем добавить его в mongodb для соответствующего подписчика. Предположительно абонентская биржа должна добавить эту информацию в качестве нового заголовка сообщения.

Согласно документам rabbitmq, я считаю, что нет способа добиться этого. (Или, более конкретно, чтобы получить свойство 'пути доставки' ​​из доставленного сообщения, из которого мы можем получить эту информацию).

Мои вопросы:

• Можно ли добавить новый заголовок к сообщению при прохождении через обмен?
• Если это невозможно, то можем ли мы добиться этого с помощью пользовательского обмена и соответствующего плагина? Любой плагин, который я могу легко использовать для этой цели?
• Мне любопытно, почему rabbitmq не предоставляет свойство пути доставки в качестве дополнительной конфигурации?
• Есть ли другой способ добиться того же? (См. Примечание pubsubhubbub ниже)

PubSubHubbub

Вариант использования очень похож на то, что предусматривает протокол pubsubhubbub. И есть плагин rabbitmq, также называемый rabbithub. Однако наша система будет закрытой, и я полагаю, что использование протокола с использованием веб-хука будет слишком сложным по сравнению с прослушиванием в одной очереди (и с точки зрения производительности).

Answer 1

Производитель (клиент RMQ) сообщения должен добавить все требуемые заголовки (включая идентификационные данные отправителя) перед его созданием (публикацией) в RMQ. Эти заголовки используются для маршрутизации.

Если во время передачи сообщение (включая заголовки) необходимо преобразовать (например, добавив новые заголовки), его необходимо отправить преобразователю (другому клиенту RMQ). Этот трансформер по сути станет новым издателем.

Фактический потребитель должен получить свои предполагаемые сообщения (на которые он подписан) через одну очередь. Маршрутизация всех его подписанных сообщений должна быть организована на RMQ Exchange.

Управление последними обновлениями "K" не должно быть обязанностью производителя или потребителя. Итак, это должно быть сделано в трансформаторе. Сообщения производителей должны быть направлены в этот преобразователь (для хранения) перед дальнейшей переадресацией на обмены, откуда потребители потребляют.