Делает RabbitMq, делают циклический алгоритм от обмена до очередей
Я в настоящее время оцениваю системы очереди сообщений, и RabbitMq походит на хорошего кандидата, таким образом, я рою немного больше в него.
Для предоставления небольшого контекста, я надеюсь иметь что-то как одно обменное выравнивание нагрузки публикация сообщения нескольким очередям. Я не хочу копировать сообщения, таким образом, обмен разветвления на выходе не является опцией.
Также причина, я думаю о наличии нескольких очередей по сравнению с одной очередью, обрабатывающей циклический алгоритм w/потребители, состоит в том, что я не хочу, чтобы наша единая точка отказа была на уровне очереди.
Кажется, что я мог добавить некоторую логику на стороне издателя для моделирования того поведения путем редактирования клавиши маршрутизации и имения в распоряжении соответствующей привязки. Но это - своего рода пассивный подход, который не взял бы темп потребления сообщения на каждой очереди во внимание, потенциально ведя для заполнения одной очереди, если пользовательские приложения для той очереди мертвы.
Я искал более превентивный путь с обменной стороны объекта, которая решит, куда отправить следующее сообщение на основе каждого размера очереди или чего-то вроде той природы.
Я читал о Alice и доступных УСПОКОИТЕЛЬНЫХ API, но это кажется своего рода мощным решением реализовать быстрые решения по маршрутизации.
Кто-либо знает, является ли циклический алгоритм между обменом очереди выполнимым w/RabbitMQ затем?Спасибо.
2 ответа
В модели AMQP биржи, как правило, не имеют состояния, хотя в последнее время проводились эксперименты по обмену с отслеживанием состояния, когда теперь существует как система для управления плагинами RabbitMQ, так и для предоставления новые экспериментальные типы обмена.
Нет ничего, что делало бы то, что вы хотите, я не думаю, хотя я не совсем уверен, что понимаю требование. Если бы не точка единой точки отказа, решила бы ваша проблема наличие единой очереди с рабочими, считывающими из нее? Если это так, то ваша проблема сводится к настройке RabbitMQ в конфигурации высокой доступности, которая позволяет вам использовать это решение. Есть несколько подходов к этому: либо используйте HALinux и общее хранилище, чтобы получить активный / пассивный HA с быстрым переключением при отказе, либо настроить более одного параллельного брокера и выполнить дедупликацию на клиенте, возможно, используя для этого redis или что-то подобное.
Я предлагаю снова задать ваш вопрос в списке рассылки rabbitmq-Discussion, где больше людей смогут высказать свои предложения и где обсуждение может быть заархивировано для потомков.
Согласитесь с Тони на подходе.
Вот «мэшап» RabbitMQ, Redis, который вы можете использовать вместо собственного катания - http://xing.github.com/beetle/