En

JazzTeam Software Development Company

Agile Java Development

RabbitMQ. Shovel plugin

Основная идея данной статьи — рассказать, в каких случаях можно использовать shovel плагин, как его активировать и настроить, а также объяснить разницу между динамическим и статическим объявлением shovel плагина.

Использование Shovel plugin

Иногда может возникнуть ситуация, когда необходимо надежно и постоянно перемещать сообщения из источника (например, очередь — queue) одного маршрутизатора в другой маршрутизатор (например, точка обмена — exchange).

Shovel (буквально «лопата») — механизм передачи сообщений из одного объекта (очереди) в другой. Объекты могут принадлежать как одному серверу, так и разным. При этом на целевом сервере Shovel plugin может быть неактивен, а начиная с версии 3.7 даже могут использовать разные версии протоколов — AMQP 0.9.1 или AMQP 1.0.

Сценарий использования: необходимость передать сообщение из одного приложения в другое, при этом каждое из приложений взаимодействует только с одним виртуальным хостом (Virtual host) и ничего не знает о другом приложении.

Существует 2 способа объявления shovel: статический и динамический. Различия между ними приведены в таблице ниже:

Установка и настройка

Установка

Для использования возможностей плагина его необходимо просто включить. Для этого нужно выполнить команды из каталога sbin:
rabbitmq-plugins enable rabbitmq_shovel rabbitmq_shovel_management
Далее потребуется перезапуск RabbitMQ service.

После этого появятся новые секции в меню Admin:

Настройка

Важно отметить, что разобранные далее примеры были выполнены на версии RabbitMQ 3.3.5. Поэтому названия некоторых переменных могут отличаться или отсутствовать обязательные переменные.

До того как рассказывать подробнее о типах shovel, необходимо внести больше ясности о режимах подтверждения сообщений:

Статическое определение

Для того чтобы создать статический shovel, необходимо описать его в файле конфигурации rabbitmq.config в секции rabbitmq_shovel:

Давайте разберёмся, что же было настроено:

После перезапуска сервера RabbitMQ можно увидеть, что был создан статический shovel, который будет перенаправлять сообщения из локального сервера с Virtual host — host2, на удалённый сервер с Virtual host — host_3. При этом, если возникнут какие-то проблемы в конфигурации, например, неверно заданы данные авторизации, необходимо будет выполнять перезапуск сервера.

Динамическое определение

При динамическом определении создать shovel можно несколькими способами:

Рассмотрим на примере Rest API. Для этого отправим PUT-запрос по адресу /api/parameters/shovel/{{virtual_host}}/{{shovel_name}}, создающий shovel, который:

  1. Будет забирать сообщения с локального сервера на host-е — host1 из очереди test1_q.
  2. Отправит сообщение на локальный сервер на host — host2, в exchange
    TEST2.
  3. Переподключение выполняется в течение 10 секунд, за один раз забирается 2 сообщения. Подтверждение происходит после того, как сообщения подтверждаются в пункте назначения.

Итоговое тело запроса в формате json:
{
«value»: {
«src-uri»: «amqp://user@/host1»,
«src-queue»: «test1_q»,
«dest-uri»: «amqp://user@/host2»,
«dest-exchange»: «TEST2»,
«ack-mode»: «on-confirm»,
«reconnect-delay»: 10,
«prefetch-count»: 2
}
}

В результате выполнения запроса появится новый shovel:

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

Выводы

Shovel плагин является мощным и гибким инструментом для переотправки сообщений между серверами RabbitMQ или внутри одного сервера. При этом важно понимать, что его задача заключается не в том, чтобы не перенаправлять большой поток сообщений от “верхнеуровневых” серверов RabbitMQ к серверами “нижнего” уровня. Для это цели лучше подойдёт Federation плагин.

Когда использовать статическое или динамическое объявление shovel, нужно решать в каждом отдельном случае, если требуется больше гибкости в настройке и скорости создания — лучше использовать динамическое объявление. Если же изменения в конфигурации не будут вноситься, и нужна большая надежность, тогда лучше будет использовать статистическое объявление.

Использованные ссылки

, , , ,