2015-04-23 3 views
1

Предположим, у вас есть несколько продюсеров и один потребитель, который хочет получать постоянные сообщения от всех доступных издателей.Как сбалансировать запросы издателей с помощью RabbitMQ?

Производители работают с разной скоростью. Предположим, что система A производит 10 запросов/сек и запрос системы B 1/сек. Поэтому, если вы используете единственную очередь, вы будете обрабатывать 10 сообщений от A, а затем 1 сообщение от B.

Но что, если вы хотите сбалансировать нагрузку и обработать одно сообщение от A, а затем одно сообщение от B и т. Д.? Потребление из нескольких очередей не является хорошим вариантом, потому что мы не можем использовать подстановочные знаки в этом случае.

Update:
Очередь на производителя кажется, лучший подход. Производители не знают своей скорости, которая постоянно меняется. Имея одну очередь для каждого потребителя, я могу подписаться на одну тему и получать сообщения от всех доступных издателей. Но, имея очередь на одного продюсера, мне нужно самому закодировать логику:

  1. Получить все доступные очереди через плагин управления (AMQP не позволяет перечислять очереди).
  2. Фильтровать по очереди.
  3. Внедрять раунд стратегии.
  4. Внедрите механизм уведомления, чтобы подписаться на новые издатели, которые могут появиться в любой момент.
  5. Удалите ненужную очередь, когда издатель исчез, и клиент прочитал все сообщения.

Ну, это кажется довольно простым, но я думал, что брокер может предоставить всю эту функциональность без какой-либо кодировки. В случае с одной очередью я просто создаю одну постоянную очередь, привязываю ее к обмену темами, а затем запускаю любое количество издателей, отправляющих сообщения в эту тему. Этот вариант работает почти из коробки.

+0

Непонятно, что вы подразумеваете под «не может использовать привязку подстановочных знаков». Пожалуйста, уточните свой вопрос с более подробной информацией о том, почему несколько очередей невозможно. –

ответ

0

Вы можете использовать Priority Queue Support и связывать приоритет в соответствии с производительностью. С оговоркой, что приоритет должен быть задан с осторожностью (например, если потребительская скорость ниже системы B, потребитель будет потреблять только сообщения от B), и производители должны знать о своей скорости производства.

Другим вариантом рассмотрения является создание трех типов очередей в соответствии с производительностью: HIGH, MEDIUM, LOW. Три очереди привязаны к обмену с набором ключей привязки в соответствии с производительностью. Это можно сделать с помощью.

Потребитель будет потреблять сообщения из этих трех очередей, используя стратегию раунда. С оговоркой, что производители должны знать о своей скорости производства.

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

Смежные вопросы