Порівняння сервісів черг Azure Queues і Service Bus Queues

      Microsoft Azure підтримує два типи механізмів черг: Azure Queues і Service Bus Queues .
 
 Azure Queues , є частиною інфраструктури Azure storage , надаючи простий REST-орієнтований Get / Put / Peek інтерфейс для надійної, гарантованої доставки повідомлень всередині сервісу або між кількома сервісами.
 
 Service Bus Queues — це частина інфраструктури Azure messaging , яка займається чергами, публікацією / підпискою, веб-сервісами та патернами інтеграції (більше про це — Overview of Service Bus Messaging Patterns ).
 
Сервіси працюють паралельно, Azure Queues з'явився раніше, як окремий механізм черг, побудований поверх сервісів зберігання даних Azure.
Service Bus Queues побудовані поверх інфраструктури «брокерів повідомлень», розробленої для зв'язку додатків або компонентів додатка, які можуть вимагати підтримки різних протоколів, працювати в різних доменах або мережевих оточеннях.
 
Дана стаття порівнює дві цих системи черг, акцентуючи увагу на відмінностях в їх поведінці і реалізації. Також стаття дає поради з вибору типу черги, яка краще підійде вашого додатком.
 
 
 

Міркування з приводу вибору технології

І Azure Queues і Service Bus Queues є сервісами черг на платформі Microsoft Azure. У них дещо різний набір можливостей, так що ви можете використовувати один з них, або інший, або обидва разом — дивлячись, що потрібно вашому додатком. Нижче наведені рекомендації по вибору.
 
Отже, вам слід вибрати Azure Queues , якщо:
 
     
  • Вашому додатку потрібно зберігати в одній черзі понад 80 ГБ даних, при цьому кожне повідомлення існує не більше 7 днів.
  •  
  • Вашому додатку необхідно відстежувати стан обробки повідомлення в черзі. Наприклад, ви хочете бути в курсі падіння Воркер, який обробляв повідомлення, і при настанні цієї події передати подальшу обробку іншому Воркер.
  •  
  • Вам потрібні логи всіх транзакцій вашої черги.
  •  
 
 Вам слід вибрати Service Bus Queues , якщо:
 
     
  • Вам потрібно мати можливість отримувати повідомлення без постійного «Поллінг». Service Bus Queues підтримує TCP-протокол, що дозволяє оперативно отримувати інформацію про нові повідомлення.
  •  
  • Вам потрібно гарантувати збереження порядку обробки повідомлень (FIFO).
  •  
  • У вас є досвід роботи з Service Bus for Windows Server і ви хочете використовувати його при роботі з чергами в Azure.
  •  
  • Ви хочете автоматично детектувати дублікати повідомлень.
  •  
  • Ви хочете в своєму додатку обробляти повідомлення паралельно в так званих «потоках» (повідомлення асоціюються з потоком по SessionId ). У цій моделі кожен вузол додатки, що одержує повідомлення, відповідає за обробку одного потоку. Коли потік переданий на обробку вузлу, останній може працювати з потоком з використанням транзакцій.
  •  
  • Ваше додаток вимагає транзакційності при відсилання або прийомі групи повідомлень.
  •  
  • Час життя (TTL) повідомлення може перевищувати 7 днів.
  •  
  • Вашому додатку потрібно обробляти повідомлення розміром більше 64 КБ (але не більше 256 КБ).
  •  
  • Вам необхідно забезпечити модель безпеки на основі ролей, реалізувати різні рівні прав доступу як для постачальників, так і для споживачів повідомлень.
  •  
  • Загальний розмір усіх повідомлень в черзі не перевищує 80 ГБ.
  •  
  • Ви хочете використовувати протокол AMQP 1.0 для роботи з повідомленнями. Більше інформації тут — Service Bus AMQP Overview .
  •  
  • Ви припускаєте теоретичну можливість переходу від моделі «один постачальник, один одержувач» до моделі, де повідомлення можуть генеруватися декількома постачальниками і перенаправлятися більш ніж одному одержувачу (можливо, за якимись правилами фільтрації).
  •  
  • Вам потрібна гарантія доставки типу «максимум одного разу» ("At-Most-Once") і ви не хочете будувати для цього спеціальну інфраструктуру.
  •  
  • Вам потрібна можливість пакетної відправки і прийому повідомлень.
  •  
  • Вам потрібна повна інтеграція з Windows Communication Foundation (WCF) стеком і платформою. NET Framework.
  •  
 
 

Порівнюючи Azure Queues і Service Bus Queues

 
Таблиці в наступних секціях розбиті на логічні групи, кожна з яких порівнює Azure Queues і Service Bus Queues за деякими параметрами.
 
 

Фундаментальні можливості

                                                               
Критерій порівняння Azure Queues Service Bus Queues
Гарантія збереження черговості Ні Так — FIFO
(Через використання сесій)
Гарантія доставки «Мінімум одного разу» «Мінімум одного разу»
«Максимум одного разу»
Підтримка транзакцій Ні Так
(Через використання локальних транзакцій)
Метод отримання Чи не блокується
(Завершується негайно якщо немає нових повідомлень)
блокується з або без таймаута
(Див. "Comet technique ")
 
 Чи не блокується
(Через використання. NET API)
«Проштовхування» повідомлень сервером на клієнт Ні Так
 OnMessage і OnMessage sessions . NET API
Спосіб отримання Peek & Lease Peek & Lock
 Receive & Delete
Ексклюзивний доступ до повідомлення На основі Lease На основі Lock
Тривалість таймаута Lease / Lock 30 секунд (за замовчуванням)
 7 днів (максимум)
 (Можна оновити або скинути за допомогою UpdateMessage API)
60 секунд (за замовчуванням)
(Можна оновити або скинути за допомогою RenewLock API)
Гранулярність Lease / Lock На рівні повідомлень
(Кожне повідомлення може мати свій таймаут, для кожного повідомлення його можна змінити за допомогою UpdateMessage API)
На рівні черзі
(Кожна чергу має свій таймаут, який поширюється на всі повідомлення в цій черзі, таймаут можна оновити за допомогою RenewLock API)
Пакетне отримання Так
(При отриманні явно вказується, скільки повідомлень потрібне, максимум — 32)
Так
(Неявно через включення настройки предзагрузкі або явно — через транзакції)
Пакетна відправка Ні Так
 (Через транзакції або пакетну відправку на стороні клієнта)
 
 
Додаткова інформація
 
     
  • Якщо ви вже використовуєте Azure Storage Blobs і Tables і почнете використовувати черзі — у вас як і раніше є гарантована доступність сервісів в межах 99.9%. Якщо ви використовуєте Blobs і Tables спільно з Service Bus Queues — надійність буде менше.
  •  
  • Гарантований порядок доставки повідомлень (FIFO) в Service Bus Queues вимагає використання транзакцій. Якщо додаток падає під час того, як повідомлення знаходиться в режимі Peek & Lock , після перезапуску програми воно отримає те ж саме повідомлення, як тільки закінчиться його час життя (TTL).
  •  
  • Azure Queues створений для підтримки стандартних сценаріїв роботи з чергами, такими як поділ компонентів додатка для збільшення масштабованості і стійкості до збоїв окремих компонентів.
  •  
  • Service Bus Queues підтримує модель гарантії доставки «Мінімум одного разу» (At-Least-Once). Крім того, модель «Максимум одного разу» може бути реалізована за допомогою транзакцій і атомарного отримання повідомлень з оновленням стану сесії. Сервіс Azure Workflow використовує цю техніку для забезпечення своєї гарантії «Максимум одного разу».
  •  
  • Azure Queues надає уніфікований і консистентних інтерфейс доступу, аналогічний інтерфейсу доступу до таблиць і блоб, що може бути зручно при необхідності використання всіх цих сервісів.
  •  
  • Service Bus Queues надає підтримку локальних транзакцій в контексті кожної черги.
  •  
  • Режим «Receive and Delete» підтримуваний Service Bus Queues дозволяє знизити кількість операцій з отримання повідомлень в обмін на зменшення гарантії їх отримання.
  •  
  • Azure Queues дозволяє оперувати величиною таймаута обробки повідомлень. Воркер може швидко обробляти «короткі» повідомлення, а якщо він раптом впаде — повідомлення будуть оперативно передані іншій Воркер. У той же час, якщо Воркер просто потрібно більше часу для обробки повідомлення — він може збільшити його таймаут, даючи зрозуміти, що обробка повідомлення все ще ведеться.
  •  
  • Azure Queues дозволяють задати таймаут «невидимості» повідомлення при його публікації. Повідомлення стане доступно споживачеві тільки по закінченню цього таймаута. Service Bus Queues теж дозволяє задавати таке таймаут, але тільки на рівні метаданих черги.
  •  
  • Максимальний таймаут блокируемой операції отримання повідомлень в Service Bus Queues становить 24 дні. Однак при використанні REST-інтерфейсу цей таймаут становить 55 секунд.
  •  
  • Пакетні операції на стороні клієнта, що надаються Service Bus Queues дозволяють скомпонувати кілька повідомлень в одну операцію відправки. Пакетна відправка доступна тільки для асинхронної операції відправки.
  •  
  • Підтримка до 200 ТБ даний в чергах Azure Queues (і навіть більше у випадку віртуалізації акаунтів) і необмежену кількість черг робить цей сервіс ідеальною платформою для SaaS провайдерів.
  •  
  • Azure Queues надає гнучкий і продуктивний механізм делегування доступу.
  •  
 
 
Додаткові можливості
                                                                                            
Критерій порівняння Azure Queues Service Bus Queues
Запланована доставка Так Так
Автоматична маркування «мертвих» повідомлень Ні Так
Збільшення часу життя повідомлення в черзі Так
(Оновлення таймаута окремо для кожного повідомлення в черзі)
Так
(Окрема API-функція)
Підтримка оброблених не до кінця повідомлень Так Так
Оновлення повідомлення Так Так
Лог транзакцій на стороні сервера Так Ні
Метрики сховища Так
 Хвилинні метрики: в реальному часі для доступності, TPS, кількості викликів API, кількості помилок і т.д., див About Storage Analytics Metrics
Так
(Метод GetQueues )
Управління станом Ні Так
 Microsoft.ServiceBus.Messaging.EntityStatus.Active ,
 Microsoft.ServiceBus.Messaging.EntityStatus.Disabled ,
 Microsoft.ServiceBus.Messaging.EntityStatus.SendDisabled ,
 Microsoft.ServiceBus.Messaging.EntityStatus.ReceiveDisabled
Авто перенаправлення повідомлень Ні Так
Очищення всієї черги Так Ні
Групи повідомлень Ні Так
(Через сесії повідомлень)
Стан додатки для групи повідомлень Ні Так
Детектування дублікатів Ні Так
(Конфігурується на стороні відправника)
Інтеграція з WCF Ні Так
(Надаються WCF — Біндінг)
Інтеграція з WF Зовнішня
(Вимагає побудови власних WF activities)
Вбудована
(Надаються WF activities)
Групи перегляду повідомлень Ні Так
Вибірка повідомлень певних повідомлень по ID сесії Ні Так
 
 
Додаткова інформація
 
     
  • Обидві технології черг дозволяють відкласти доставку повідомлення на певний час.
  •  
  • Автоматичне перенаправлення повідомлень дозволяє зібрати в одну чергу повідомлення з тисяч черг. Ви можете використовувати цей механізм для забезпечення безпеки, контролю процесів та ізоляції постачальників повідомлень один від одного.
  •  
  • Azure Queues підтримує можливість зміни вмісту повідомлення. Ви можете використовувати це для поновлення прогресу виконання завдання, відповідної цьому повідомленням, так щоб у разі необхідності показати цю інформацію користувачеві або продовжити обробку з потрібного етапу, а не спочатку. У Service Bus Queues ви можете реалізувати подібний сценарій з використанням сесій. Сесія дозволяє вам зберегти і отримати стан додатки (з використанням методів SetState і GetState ).
  •  
  • Механізм обробки «мертвих листів», який підтримується в Service Bus Queues, дозволяє ізолювати повідомлення, які не можуть бути успішно оброблені одержувачем або у яких закінчився термін життя (TTL). Такі повідомлення будуть переміщені в спеціальну чергу, яка називається $ DeadLetterQueue.
  •  
  • Частково подібний механізм може бути реалізований в Azure Queues на стороні додатку — перевіряючи властивість DequeueCount можна перенаправляти певні повідомлення в іншу чергу.
  •  
  • Azure Queues дозволяє вам отримати детальний лог всіх транзакцій для кожної черги, а також деякі агреговані метрики. Обидві можливості досить корисні для налагодження та розуміння того, як ваші програми використовують чергу. Також вони допомагають оптимізувати продуктивність і мінімізувати витрати при використанні черг.
  •  
  • Концепт «сесій повідомлень», підтримуваний в Service Bus Queues, дозволяє кожному повідомленням належати до деякої логічної групі, яка може бути асоційована з окремим одержувачем. Ви можете використовувати цю функціональність, заповнюючи поле SessionID для кожного повідомлення. Одержувач потім може запитувати з черги повідомлення тільки з певним SessionID .
  •  
  • Механізм детектування дублікатів, підтримуваний в Service Bus Queues, автоматично видаляє з черги повідомлення з однаковими MessageID .
  •  
 
 

Місткість і квоти

                                 
Критерій порівняння Azure Queues Service Bus Queues
Максимальний розмір черги 200 ТБ
(Обмежено загальним обсягом сховища для одного аккаунта)
Від 1 ГБ to 80 ГБ (визначається на етапі створення черги)
Максимальний розмір повідомлення 64 КБ
(48 Кб при використанні Base64 кодування) Azure підтримує повідомлення великих розмірів, комбінуючи черги і Блоб — так що в одному повідомленні ви можете зберігати фактично до 200 ГБ даних
256 КБ (включаючи заголовок і тіло повідомлення, максимальний розмір заголовка — 64 КБ)
Максимальний час життя повідомлення 7 днів Не обмежено
Максимальна кількість черг Не обмежено 10000
(На один простір імен, може бути збільшено)
Максимальна кількість клієнтів Не обмежено Не обмежено
(100 сполук для клієнтів TCP-протоколу)
 
 
Додаткова інформація
 
     
  • Для Azure Queues, якщо контент повідомлення містить символи, які не можна зберігати в XML, він повинен бути закодований в Base64 . Зверніть увагу, що в цьому випадку розмір корисних даних у повідомленні не повинен перевищувати 48 КБ.
  •  
  • Для Service Bus Queues кожне повідомлення складається із заголовка і тіла. Загальний розмір повідомлення не повинен перевищувати 256 КБ.
  •  
  • Коли клієнти використовують Service Bus Qeues по протоколу TCP, загальна кількість активних сполук до однієї черги не повинно перевищувати 100. Враховуються як відправники, так і одержувачі. Якщо ця квота досягнута, наступні запити будуть відхилені. Цей ліміт не поширюється на клієнтів, які використовують чергу через REST API.
  •  
  • Service Bus Queues має ліміти на розмір черги. Вони задаються при створенні черги і можуть становити від 1 до 80 ГБ. Якщо ліміт досягнутий — наступний повідомлення не будуть прийняті в чергу. Більше інформації — Azure Service Bus Quotas .
  •  
  • Якщо вам потрібно більш 10000 черг Service Bus Queues в одному просторі імен — ви можете звернутися до техподдержке Azure і попросити збільшити ліміт для вас. Але більш простим і швидким може бути створення додаткового простору імен через Microsoft Azure Management Portal.
  •  
 
 

Управління та доступ

                                                   
Критерій порівняння Azure Queues Service Bus Queues
Протокол управління REST через HTTP / HTTPS REST через HTTPS
Протокол операцій REST через HTTP / HTTPS REST через HTTPS
 AMQP 1.0 Standard (TCP with TLS)
. NET API Так
(. NET Storage Client API)
Так
(. NET API для брокерів повідомлень)
Native C + + Так Ні
Java API Так Так
PHP API Так Так
Node.js API Так Так
Підтримка довільних метаданих Так Ні
Правила іменування черг До 63 символів
(Букви повинні бути в нижньому регістрі)
До 260 символів
(Імена черг регістронезавісімий)
Отримання кількості повідомлень в черзі Так
(Зразкове, без обліку повідомлень, для яких закінчився TTL і вони знаходяться в процесі видалення)
Так
(Точне)
Функція перегляду повідомлень в черзі без їх вибірки Так Так

Додаткова інформація
  • Azure queues надає можливість додати до черги довільну кількість метаданих у формі пар ключ / значення.
  • Обидві технології черг дозволяють переглянути повідомлення в черзі без їх зміни \ видалення, що може бути корисно для реалізації інструментів перегляду черг.
  • Service Bus підтримує. NET API на базі TCP-з'єднання, що працює більш ефективно ніж REST-запити або протокол AMQP 1.0.
  • Ім'я черзі в Azure Queue може бути довжиною від 3 до 63 символів, може включати букви в різному регістрі, цифри і дефіси. Більше інформації — Naming Queues and Metadata .
  • Ім'я черзі в Service Bus Queue може бути до 260 символів і може включати крім букв і цифр також символи '.', '-' і '_'.

Продуктивність
Критерій порівняння Azure Queues Service Bus Queues
Максимальна пропускна здатність До 2000 повідомлень в секунду
(Для повідомлень розміром в 1 КБ)
До 2000 повідомлень в секунду
(Для повідомлень розміром в 1 КБ)
Середня затримка 10 мс
(При відключеному TCP Nagle)
20-25 мс
Поведінка при перевантаженні HTTP-код 503
(Запит не оплачується)
HTTP-код 503
(Запит не оплачується)

Додаткова інформація
  • Одна чергу Azure Queue може обробляти до 2000 транзакцій в секунду. Транзакцією вважаються операції a Put , Get і Delete . Відправлення одного повідомлення в чергу (Put ) вважається однією транзакцією, але отримання повідомлення часто є двокроковий операцією — повідомлення потрібно спочатку отримати (Get ), а потім видалити з черги (Delete ), що дає в підсумку дві транзакції. Не забувайте, що з метою зниження кількості транзакцій ви можете отримати одним запитом до 32 повідомлень, хоча видаляти їх з черги все-одно доведеться по одному. Для збільшення пропускної здатності ви можете створити більше черг (загальна кількість не обмежена).
  • Коли ваш додаток намагається обробляти більше 2000 повідомлень в секунду, ви будете отримувати відповідь "HTTP 503 Server Busy". У цьому випадку вам слід зменшити частоту звернень до черги.
  • Затримка в Azure Queues в середньому 10 мс при обробці повідомлень до 10 КБ при роботі з віртуальної машини сервісу Azure, розташованої в тому ж регіоні, що і черга
  • Обидва сервіси черг відхиляють запити до черг у разі перевищення максимально можливої ​​пропускної здатності. Обидва сервіси не вважають такі запити оплачуваними.
  • Тести продуктивності Service Bus Queues показали, що одна черга може обробляти до 2000 повідомлень в секунду при розмірі повідомлення в 1 КБ. Для забезпечення більшої пропускної здатності використовуйте кілька черг. Більше інформації — Best Practices for Performance Improvements Using Service Bus Brokered Messaging .
  • Коли максимальна пропускна здатність досягнута при використанні Service Bus Queues ви будете отримати виняток ServerBusyException (при використанні. NET API) або "HTTP 503 Server Busy" (при використанні REST API).

Аутентифікація і авторизація

Критерій порівняння Azure Queues Service Bus Queues
Аутентифікація За симетричного ключу За симетричного ключу
Модель контролю доступу делегованих доступ по SAS токені RBAC через ACS
Об'єднання провайдерів ідентифікації Ні Так

Додаткова інформація
  • Кожен запит до черги повинен пройти аутентифікацію. Черги з публічним анонімним доступом не підтримуються. Використовуючи SAS, ви можете побудувати різні сценарії роботи вашої програми.
  • Схема аутентифікації в Azure Queues полягає у використанні симетричного ключа, який являє собою SHA-256 хеш-суму, закодовану в Base64 . Більше інформації про аутентифікації в Azure Queues — Authenticating Access to Your Storage Account , для Service Bus Queues — Shared Access Signature Authentication with Service Bus .
  • Microsoft Azure Active Directory Access Control (також відомий як Access Control Service або ACS) підтримуваний Service Bus, надає три різних ролі: Admin , Sender і Receiver , який в даний момент не підтримуються Azure Queues.
  • Оскільки Service Bus підтримує інтеграцію з ACS, ви можете налаштувати федерацію з Active Directory (через використання ADFS) і загальнодоступними провайдерами ідентифікації, такими як Live ID, Google, Facebook або Yahoo.

Ціни

Критерій порівняння Azure Queues Service Bus Queues
Вартість транзакції $ 0.0005
(За 10,000 транзакцій)
$ 0.01
(За 10,000 повідомлень)
Оплачувані операції Всі Тільки Send і Receive
(Інші — безкоштовні)
Холості транзакції Оплачуються
(Запит повідомлення при порожній черзі стоїть стільки ж, скільки запит за наявності повідомлень)
Оплачуються
(Запит повідомлення з порожньої черги оплачується як отримання одного повідомлення)
Вартість зберігання даних $ 0.07
(За ГБ на місяць)
$ 0.00
Вартість зовнішнього трафіку $ 0.12 — $ 0.19
(Залежить від дата-центру)
$ 0.12 — $ 0.19
(Залежить від дата-центру)

Додаткова інформація
  • Передача даних оплачується виходячи із загальної кількості даних, що виходять з дата-центру Azure в Інтернет за оплачувану період.
  • Передача даних між сервісами Azure всередині одного дата-центру не оплачується.
  • На даний момент вхідний трафік не оплачується.
  • Вартість ACS-транзакцій при використанні Service Bus Queues вельми незначна. Service Bus Queues генерує один ACS токен на кожну чергу і використовує його поки він не застаріє (близько 20 хвилин). Таким чином, кількість операцій не прямо пропорційно кількості ACS-транзакцій.
  • У ситуаціях, коли повідомлення має бути отримано дуже швидко, економічно ефективніше використовувати Service Bus Queues і механізм повідомлень про прихід нових повідомлень.

Зауваження
Ціни можуть змінюватися. Заглядайте на сторінку Pricing Overview .

Висновок


Рішення про вибір між Azure Queues і Service Bus Queues залежить від багатьох факторів, потреб вашого додатки і його архітектури. Якщо ви вже використовуєте інші сервіси Azure, такі як таблиці або Блоб — вам буде просто почати користуватися Azure Queues, особливо якщо вам потрібні тільки базові сценарії використання черг. З іншого боку, Service Bus Queues пропонує ряд додаткових можливостей, таких як сесії, транзакції, детектування дублікатів, автоматичну обробку «мертвих» повідомлень, що може бути необхідним для вашої програми.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.