Делает ли RabbitMq циклический перебор от обмена к очередям

Question

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

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

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

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

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

Я читал об Алисе и доступных API-интерфейсах RESTful, но это похоже на мощное решение для реализации решений по быстрой маршрутизации.

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

Answer 1

Обмены, как правило, не сохраняют состояния в модели AMQP, хотя в обмене с состоянием в последнее время проводились некоторые эксперименты, когда появилась система управления плагинами RabbitMQ и предоставления новых экспериментальных типов обмена.

Нет ничего, что делает то, что вы хотите, я не думаю, хотя я не совсем уверен, что понимаю требование. Помимо точки единой точки отказа, решит ли ваша проблема наличие единой очереди, в которой рабочие читают из нее? Если это так, то ваша проблема сводится к настройке RabbitMQ в конфигурации HA, которая позволяет вам использовать это решение. Для этого есть несколько подходов: либо использовать HALinux и совместно используемое хранилище для получения активного / пассивного HA с быстрым переключением при сбое, либо настроить более одного параллельного посредника и выполнить дедупликацию на клиенте, возможно, используя redis или аналогичный для этого.

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

Answer 2

Одной из встроенных функций, позволяющих вам делиться формой обмена формой с очередями, но не совсем круговой, является последовательное хеширование. rabbitmq_consistent_hash_exchange

Как тоже https://medium.com/@eranda/rabbitmq-x-consistent-hashing-with-wso2-esb-27479b8d1d21

Бумага, чтобы объяснить, это помещает очереди в взвешенном распределении по кругу, а затем, отправляя случайный ключ маршрутизации, отправляет в ближайшую очередь. http://www8.org/w8-papers/2a-webserver/caching/paper2.html

Answer 3

Согласитесь с Тони на подходе.

Вот «коллаж» из RabbitMQ, Redis, который вы можете использовать вместо того, чтобы катать свой собственный - http://xing.github.com/beetle/