Масштабировать подписчика брокера сообщений, предотвращая двойное сообщение

Question

Я думал о классическом брокере сообщений (например, RabbitMQ или Azure Service Bus), используемом в режиме pub / sub.

Давайте поговорим об этом примере:

-Публикатор 1 (Пример заказа эмитента)

-Подписчик А (Биллинг)

-Подписчик Б (Отгрузка)

Что произойдет, если я хочу уменьшить масштабодин подписчик (например, подписчик B)?

У меня наверняка будет такая комбинация:

-Publisher 1 (Пример отправителя заказа)

-Подписчик A(Биллинг)

-Подписчик B - узел 1 (Отгрузка)

-Подписчик B - узел 2 (Отгрузка)

Какой шаблон следует использовать для предотвращенияПосредник сообщений отправит одно и то же сообщение на оба узла подписчика. 2?

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

Answer 1

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

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

• ваш Publisher 1 будет публиковать в теме "заказов" (например, orders/new/[ORDER_ID])
• , вы можете настроить две очереди (qa и qb):
  • добавить подписку на тему orders/new/* в каждой очереди
  • 2-я очередь будет настроена как неисключительная , которая разрешает циклическую доставку или доставку с балансировкой нагрузки длявсе подключенные потребители
• Подписчик A будет привязан к qa, а подписчики B1 и B2 будут привязаны к qb

Из-за паба / подсистемыкаждая очередь получит копию сообщения.Для эффективности постоянное хранилище в Solace основано на указателях (через счетчик ссылок), поэтому каждое сообщение записывается на диск только один раз, даже если оно копируется в несколько очередей.(в отличие от Rabbit, который записывает каждую копию на диск).

Добавление большего числа потребителей / подписчиков к qb будет динамически распределять нагрузку между ними.

Answer 2

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

Таким образом, я должен был знать прежде, буду ли я масштабировать эту службу, поскольку она изменит мою модель программирования о том, как я буду использовать клиентский API Message Broker.

-Что является лучшим методом?Никогда не используйте прямую подписку на тему, но ставьте очередь посередине, чтобы в конечном итоге масштабировать получателя в разных узлах?

Как я вижу, Solace предоставляет способ объявить очередь как подписку на тему и потреблять ее.сообщения из очереди.Как насчет Azure Service Bus и Rabbit MQ, я могу настроить их таким образом?

Спасибо за ваше терпение

Answer 3

При добавлении экземпляров одного и того же логического узла вы уменьшаете, а не увеличиваете.Оба брокера поддерживают шаблон Конкурирующие потребители и не требуют ничего особенного при масштабировании из .Сообщения будут обрабатываться только одним экземпляром, если только они не будут выполнены своевременно (в случае Azure Service Bus) или не были успешно завершены.