Можно ли приоритезировать на какой консумер (или группу) уйдет сообщение из RabbitMQ?

Question

[arturich]

Если я изначально не прав в понимании использования очередей сообщений, поправьте пожалуйста.


Хочется понимать проблему, которую я описал в заголовке.

Answer 1

[akazakou]

Есть несколько вариантов решения задачи:
1. Создается несколько точек обмена (exchanges) по разным типам сообщения и подписывать очереди для каждого consumer на эти точки обмена.
2. Создается одна точка обмена и все очереди подписываются на эту точку обмена, с указанием routing_key. Очереди подписываются на определенные routing_key (их может быть несколько)

Второй вариант более предпочтителен на мой взгляд.

Comments

[akazakou]

Junart1, Тут вся суть в том, что одного consumer можно подписать на несколько ключей. К примеру:
У нас имеется 3 consumer: consumer1, consumer2, consumer3. И у нас имеется routing_key для них вида:
foo.bar.messageType. Мы можем в конец routing_key добавить строчку с именем consumer и получить три ключа: foo.bar.messageType.consumer1, foo.bar.messageType.consumer2 и foo.bar.messageType.consumer3

Тогда можно всех консумеров настроить на получение только адресованных им сообщений

Answer 2

[subvillion]

Нет нельзя, такой концепции в RabbitMQ нет.
Реализуют по разному.
Оптимальная реализация, на мой взгляд, это 2 очереди, low и hi + коньсюмер который сначала забирает таск из hi, и только если там пусто из low.

Comments

[arturich]

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

[subvillion]

В таком случае выход один — балансировщик с обратной связью.

Все пишется в одну очередь.
Эту очередь читает 1 консьюмер, задача которого — получение информации о загруженности серверов и маршрутизация в 2 очереди srv1q и srv2q.
На серверах srv1, srv2 висит по консьюмеру на соответствующих очередях.

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

Прежде чем городить что-то монструозное, рекомендую ознакомиться с этой статьей одного из моих коллег, вполне может быть, что это и есть решение habrahabr.ru/post/153431/

[arturich]

Спасибо, статью уже читал

Answer 3

[tarasbogach]

http://www.rabbitmq.com/amqp-0-9-1-quickref.html
basic.qos(long prefetch-size, short prefetch-count, bit global) ➔ qos-ok
Specify quality of service.

Так можно изменить вероятность для воркера.