Аварийное переключение с Spring AMQP и RabbitMQ HA

Question

В нескольких статьях предлагается использовать балансировщик нагрузки перед кластером RabbitMQ.

Однако, есть также несколько ссылок, что Spring AMQP использует некоторые Реализация аварийного переключения, например, сброс соединения при возвращении брокера к жизни.

У меня есть несколько вопросов по этой теме (учитывая, что эти статьи более или менее старые и сегодня 2018 год)

• При использовании Spring AMQP все еще требуется балансировка нагрузки?

• Если все еще предлагается балансировка нагрузки, как бы я решил сродство первичной очереди с ее узлом? Было бы много взаимосвязей между узлами кластера, потому что балансировщик нагрузки циклического перебора имел бы 1- (1 / n) успешность попадания в правильный узел кластера

• Поддерживает ли Spring AMQP некоторую осведомленность о топологии, которая позволила бы ему получать данные с правильного узла?

• В некоторых статьях предлагалось, чтобы клиенты публиковали / потребляли узлы, соблюдая локальность очередей. Это все еще применяется? Как все это согласуется с учетом распределения нагрузки, аварийного переключения Spring AMQP и CachingConnectionFactory?

Может ли кто-нибудь дать ответы на эти темы, а также предоставить соответствующие ссылки, которые предоставят дополнительную информацию для проверки?

Большое спасибо

Answer 1

Для каждой из ваших пуль:

• балансировщик нагрузки не имеет смысла в конфигурации Spring AMQP по умолчанию, поскольку он открывает одно долговременное соединение, которое используется всеми пользователями. В версии 2.0 вы можете настроить RabbitTemplate на использование отдельных соединений; это потому, что это рекомендуемая конфигурация для использования другого соединения для издателей / потребителей; это будет по умолчанию в 2.1.

  • Возможно, имеет смысл использовать балансировщик нагрузки, если вы настраиваете фабрику соединений для кэширования соединений (а не только каналов), поскольку каждый компонент получает свое собственное соединение.

• См. Следующий пункт.

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

• Насколько я понимаю из нескольких дискуссий, сходство с очередью необходимо только в самых экстремальных условиях, и что в большинстве сред эта разница неизмерима. Тем не менее, среды / сети сильно отличаются, YMMV, так что вы можете захотеть проверить. Мое общее практическое правило - избегать преждевременной оптимизации, поскольку дополнительная сложность конфигурации может просто не стоить выгоды (и, возможно, у вас не будет проблем с самого начала).