Azure Сервисная шина заказала обработку сообщения

Question

Если для Azure Service Bus topi c, существует одна подписка с некоторым фильтром. Существует микросервис A, который создал SubscriptionClient для подписки с параллелизмом 1 для чтения сообщений. Также, если есть 2 такие реплики этой службы A и, скажем, есть 3 сообщения в служебной шине unpartitioned topi c, вставленной в topi c во время t1, t2 и t3.

t1 < t2 < t3

1. Есть ли вероятность, что сообщение t2 может быть доставлено по служебной шине в Replica-2 до того, как t1 будет доставлено в Replica-1?

2. Если нет, какова стратегия масштабирования для тем служебной шины при обработке подписок и добавлении реплик потребляющего микросервиса.

Примечание: По сравнению с kafka он гарантирует, что сообщение для 1 раздела доставляется только в одну реплику и в один поток, который прослушивает этот раздел и, таким образом, упорядоченная обработка сообщения гарантирована. Но не уверен, что по служебной шине topi c, как Azure По служебной шине, если несколько реплик прослушивают одну и ту же подписку с разными клиентами subscriptionClients, могут ли они получать / обрабатывать сообщения, вышедшие из строя?

Answer 1

Если вы хотите включить упорядоченную обработку сообщений с помощью Azure Service Bus, вы должны использовать Сеансы .

Вы можете использовать SessionId сообщения. в качестве эквивалента ID раздела, который вы можете использовать в Kafka. Таким образом, вы по-прежнему можете масштабировать своих потребителей, ограниченные количеством различных значений SessionId в любой момент времени.

Сеансы сообщений. Внедрить рабочие процессы, требующие упорядочения или отсрочки сообщения.

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

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

Служебная шина Разделы распределяют нагрузку по нескольким узлам и не дают никаких гарантий заказа.

Секционирование означает, что общая пропускная способность секционированной сущности больше не ограничивается производительностью одного посредника сообщений или хранилища сообщений. Кроме того, временное отключение хранилища сообщений не делает разделенную очередь или topi c недоступными.