Когда использовать лопаты RabbitMQ и когда плагин Федерации?
для компании, в которой я работаю, мы хотели бы использовать RabbitMQ в качестве основной шины сообщений. Идея, которую мы имеем, заключается в том, что каждое приложение использует свой собственный vhost для внутренней связи и что с помощью плагина shovel или federation мы могли бы поделиться определенным типом событий через несколько vhosts (возможно, даже несколько машин (некластеризованных)). Мы выбрали для применения в vhost для того чтобы отделить внутреннее сообщение от общественных событий и держать обеспеченность регулируемой для каждого приложения.
на основе информации, опубликованной на RabbitMQ веб-сайт я не получаю его, когда мне нужно выбрать лопаты или когда мне нужно выбрать плагин Федерации.
RabbitMQ имеет следующее объяснение когда использовать:
обычно вы используете лопату для связывания брокеров через интернет, когда вам нужно больше контроля, чем предоставляет Федерация.
Что такое хорошо контроль зерна в лопатах, которых мне не хватает, когда я выбираю Федерацию?
на данный момент я думаю, что предпочел бы плагин Федерации, потому что я мог бы автоматизировать inter-vhost-связь через REST API, предоставляемый плагином Федерации. В случае лопат мне нужно будет изменить конфигурацию лопаты и перезагрузить экземпляр RabbitMQ каждый раз, когда мы хотели бы поделиться событием между vhosts. Верны ли мои мысли по этому поводу?
в настоящее время мы запускаем RMQ в Windows с подключением клиентов .Сеть. В ближайшее время присоединятся клиенты Java/Perl/PHP.
подводя итог моим вопросам:
- что такое мелкозернистый контроль в лопатах, который мне не хватает, когда я
выбрать Федерацию? - правильно ли, что единственный способ изменить inter-vhost-связь, когда я использую лопаты, - это изменение файла theconfig и перезагрузка экземпляра?
- выполняет ли настройка (vhost для каждого приложения) имеет смысл или я полностью упускаю суть?
2 ответов
лопаты и очередь предоставляют различные средства для пересылки сообщений с одного узла RabbitMQ на другой.
Федеративных Обмен
с федеративным обменом очереди могут быть подключены к очереди на восходящем (исходном) узле. Кроме того, exchange на нижнем(конечном) узле получит копию сообщений, опубликованных на верхнем узле.
Федеративные биржи аналогичны привязкам exchange-to-exchange, в это, они могут (необязательно) подписаться на ограниченный набор сообщений от вышестоящего обмена.
Федеративных Очередь (Примечание: они являются новыми в RabbitMQ 3.2.x)
С Федеративной очередью потребители могут быть подключены к очереди как на восходящем(исходном), так и на нисходящем (конечном) узлах.
по сути, нисходящая очередь является потребителем в восходящей очереди, ожидая, что будут дополнительные нисходящие потребители, которые обрабатывайте сообщения так же, как потребитель, подключенный к восходящей очереди.
любые сообщения, потребляемые нижестоящей (Федеративной) очередью, не будут доступны для потребителей в вышестоящей очереди.
Использовать Случае:
Если потребители переносятся с одного узла на другой, Федеративная очередь позволит этому произойти без пропущенных сообщений или обработанных дважды.
Использовать Случае: из документов RabbitMQ
типичным использованием было бы иметь ту же самую" логическую " распределенную очередь над многими брокерами. Каждый брокер объявляет федеративную очередь с все остальные федеративные очереди вверх по течению. (Ссылки бы полный двунаправленный Граф на n очередях.)
лопата
лопаты с другой стороны, прикрепите очередь "вверх по течению" к обмену "вниз по течению". (Я помещаю термины в кавычки, потому что документация лопаты не описывает узлы с той же семантикой, что и документация Федерации.)
лопата потребляет сообщения из очереди и отправляет их в exchange на узле назначения. (Примечание: хотя обычно не обсуждается как часть этого шаблона, ничто не останавливает потребителя от подключения к очереди на исходном узле.)
чтобы ответить на конкретные вопросы:
что такое мелкозернистый контроль в лопатах, которые я когда я выбрать Федерацию?
лопата не есть для проживания на "вверх" или "вниз" узел. Его можно установить и работать от независимого узла.
лопата может создавать все элементы связи сама по себе: исходную очередь, привязки очереди и конечный обмен. Таким образом, он неинвазивен ни к источнику, ни к узлу назначения.
правильно ли, что единственное путь к изменению inter-vhost-связь, когда я использую лопаты, - это изменение theconfig файл и перезагрузка экземпляра?
это, как правило, было принято обратной стороной лопаты.
со следующей командой (предостережение: только проверено на RabbitMQ 3.1.x, и с очень специфическим rabbitmq.config файл, который содержит только ) вы можете перезагрузить конфигурацию лопаты из указанного файла. (в данном случае /etc/rabbitmq/rabbitmq.config)
rabbitmqctl eval 'application:stop(rabbitmq_shovel), {ok, [[{rabbit, _}|[{rabbitmq_shovel, [{shovels, Shovels}] }]]]} = file:consult("/etc/rabbitmq/rabbitmq.config"), application:set_env(rabbitmq_shovel, shovels, Shovels), application:start(rabbitmq_shovel).'
.
имеет ли смысл настройка (vhost для каждого приложения) или мне не хватает полностью смысл?
Это решение будет зависеть от вашего варианта использования. vhosts в первую очередь обеспечивают логическое (и доступ) разделение между очередями/обменами и авторизованными пользователями.
лопата действует как хорошо спроектированный встроенный потребитель. Он может использовать сообщения от исходного брокера и очереди и публиковать их в целевой брокер и exchange. Вы могли бы написать приложение для этого, но shovel уже сделал это правильно - если все, что вам нужно, это переместить сообщения из очереди на биржу в том же или другом брокере, shovel может сделать это за вас. Так же, как хорошее приложение, оно может объявлять обмены/очереди/привязки, повторно подключаться, изменять ключ маршрутизации и т. д. Вы можете настроить его на источнике или на брокере назначения, или даже использовать третьего брокера. Это в основном клиент AMQP.
Федерации, С другой стороны, используется для подключения вашего брокера к одному или нескольким вышестоящим брокерам, или вы даже можете создавать цепочки брокеров, сгибая топологию так, как вам нравится. Вы можете объединять обмены или очереди и, например, распространять сообщения нескольким брокерам без необходимости привязывать дополнительные очереди к теме обмена или использовать fanout exchange и выгрузка сообщений из каждой очереди на нисходящий брокер.
чтобы резюмировать, федерация работает на более высоком уровне, в то время как лопата в основном "просто" хорошо написанный клиент.
чтобы перенастроить лопату, вам, к сожалению, придется перезапустить брокера.
Я не думаю, что вам действительно нужен per app vhost. Вы можете добавить пользователя для каждого приложения в брокер без отдельных vhosts. Не уверен, что вы имеете в виду "поделиться событием между vhosts", хотя.