Сравнение сервисов очередей Azure Queues и Service Bus Queues

в 8:02, , рубрики: Microsoft Azure

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 KБ при использовании 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 предлагает ряд дополнительных возможностей, таких как сессии, транзакции, детектирование дубликатов, автоматическую обработку «мёртвых» сообщений, что может быть необходимым для вашего приложения.

Автор: tangro

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js