Вступ до Azure Service Bus

Розробка рішень на Azure на основі подій та повідомлень

Fiodar Sazanavets

Senior Software Engineer and Microsoft MVP

Queue Storage vs Service Bus

Queue Storage

Service Bus

Queue Storage

Service Bus

Точка–точка:
- Коли виробник надсилає повідомлення
- Один споживач його забирає
- Повідомлення обробляється один раз
Подібно до роботи Queue Storage

Логотип Service Bus

Модель publish–subscribe
- Кілька виробників надсилають повідомлення
- Кілька споживачів можуть отримати те саме повідомлення
Кожна підписка може фільтрувати повідомлення:
- Кожна підписка отримує релевантне
Черга — як одна скринька «Вхідні»
Топік — як список розсилки

Service Bus Topic

Вбудована надійність:
- Збої обробляються
- Автоматичні повтори
Черга невдалих повідомлень (dead-letter):
- Для повідомлень, що не доставлені
- Повідомлення можна переглянути

Надійність повідомлень

Виявлення дублікатів не дає обробити повідомлення двічі.
Якщо відправник повторює спробу і те саме повідомлення приходить знову, його розпізнають за ID повідомлення.
Дублікатів позбуваються в межах заданого вікна часу.
Це дає майже одноразову обробку, попри мережеві повтори.

Виявлення дублікатів у Service Bus

Service Bus Sessions

Service Bus Sessions забезпечують впорядковану обробку.
Пов'язані повідомлення мають спільний Session ID (наприклад, усі оновлення одного замовлення).
Кожну сесію отримує один споживач за раз.
Порядок зберігається в межах сесії, споживач може тримати легкий стан.
Кілька сесій можна обробляти паралельно, порядок у кожній зберігається.

Розробка рішень на Azure на основі подій та повідомлень