Сравнение сервисов очередей 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 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 вы можете реализовать подобный сценарий с использованием сессий. Сессия позволяет вам сохранить и получить состояние приложения (с использованием методов SetState и GetState).
• Механизм обработки «мёртвых писем», который поддерживается в Service Bus Queues, позволяет изолировать сообщения, которые не могут быть успешно обработаны получателем или у которых закончился срок жизни (TTL). Такие сообщения будут перемещены в специальную очередь, которая называется $DeadLetterQueue.
• Частично подобный механизм может быть реализован в Azure Queues на стороне приложения – проверяя свойство DequeueCount можно перенаправлять определённые сообщения в другую очередь.
• Azure Queues позволяет вам получить детальный лог всех транзакций для каждой очереди, а также некоторые агрегированные метрики. Обе возможности весьма полезны для отладки и понимания того, как ваши приложения используют очередь. Также они помогают оптимизировать производительность и минимизировать затраты при использовании очередей.
• Концепт «сессий сообщений», поддерживаемый в Service Bus Queues, позволяет каждому сообщению принадлежать к некоторой логической группе, которая может быть ассоциирована с отдельным получателем. Вы можете использовать эту функциональность, заполняя поле SessionID для каждого сообщения. Получатель затем может запрашивать из очереди сообщения только с определенным SessionID.
• Механизм детектирования дубликатов, поддерживаемый в Service Bus Queues, автоматически удаляет из очереди сообщения с одинаковыми MessageID.

Вместимость и квоты

Дополнительная информация

• Для 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 поддерживает .NET API на базе TCP-соединения, что работает более эффективно чем REST-запросы или протокол AMQP 1.0.
• Имя очереди в Azure Queue может быть длиной от 3 до 63 символов, может включать буквы в разном регистре, цифры и дефисы. Больше информации — Naming Queues and Metadata.
• Имя очереди в Service Bus Queue может быть до 260 символов и может включать кроме букв и цифр также символы ‘.’, ‘-‘ и ‘_’.

Производительность

Дополнительная информация

• Одна очередь 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).

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

Дополнительная информация

• Каждый запрос к очереди должен пройти аутентификацию. Очереди с публичным анонимным доступом не поддерживаются. Используя 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 в Интернет за оплачиваемый период.
• Передача данных между сервисами 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

Источник