Windows Azure Queues и Windows Azure Service Bus Queues: сходства и различия

  • Article

Перевод, оригинальная статья New Article: Windows Azure Queues and Windows Azure Service Bus Queues - Compared and Contrasted.

На данный момент Windows Azure предоставляет два сервиса очередей (Windows Azure Queues и Windows Azure Service Bus Queues). Мы получаем вопросы от Партнеров и Клиентов о том, когда и какой из двух сервисов рекомендуется использовать. Недавно на MSDN мы опубликовали руководство, описывающие сходства и различия данных служб, а так же предоставляющее рекомендации по сценариям их использования. Надеемся, что руководство позволит Вам сделать обоснованный выбор решения и службы, максимально соответствующего требования и задачам разрабатываемой системы или приложения. Далее приведена выдержка из статьи.

Вопросы выбора технологии

Обе службы - Windows Azure Queues и Windows Azure Service Bus – реализуют функциональность обмена сообщениями между несколькими участниками или компонентами системы. Функциональность служб различается, поэтому в зависимости от требований для проектируемой системы может быть выбрана как одна из служб, так и их совместное использование.

С точки зрения архитектора или разработчика системы использование WindowsAzureQueues является предпочтительным, когда:

  • Размер хранимых сообщений в очереди превышает 5 Гб и время пребывания сообщения в очереди не превышает 7 дней.
  • Приложение требует гибкого управления «захватом» (leasing) сообщений. Поэтому в случае сбоя экземпляра (который «захватил» сообщение рабочей роли при обработке сообщения, обработка сообщения достаточно быстро может быть возобновлена (скорее всего, другим экземпляром рабочей роли). При необходимости рабочая роль может увеличить время владения сообщением (leasing timeout), это позволяет сделать процесс обработки непрерывным.
  • Приложение должно отслеживает ход выполнения (например, процент выполнения) процесс обработки сообщения. При наличии такой информации даже в случае сбоя при обработке сообщения другой экземпляр рабочей роли будет иметь возможность продолжить выполнение задания с того места, где произошел сбой.
  • Требуется вести серверный журнал, в котором фиксируются все действия, выполняемые с очередью.

С точки зрения архитектора или разработчика системы использование WindowsAzureServiceBusQueues является предпочтительным, когда:

  • Требуется полная интеграция со стеком Windows Communication Foundation (WCF).
  • Требуется автоматическое обнаружения дубликатов сообщения.
  • Необходимо иметь возможность обработки нескольких сообщений как единой логической группы.
  • При отправке или получения сообщений из очереди требуется соблюдение принципов транзакционности и атомарности (т.е. либо удалось получить все запрашиваемые сообщения, либо операция отказывается для всех сообщений, вне зависимости от того было ли успешным получение какого-либо сообщения).
  • Время пребывания сообщения в очереди (time-to-leave, TTL) может превышать 7 дней.
  • Размер одного сообщения может превышать 64 КБ, но при этом не быть более 256 КБ.
  • Требуется гарантированное соблюдение принципа FIFO (first-in-first-out).
  • Приложение должно получать сообщения без необходимости опроса очереди. Для Service Bus это достигается посредством использования операции long-polling.
  • Для очереди требуется разграничивать права доступа или установить различные права для отправителя (sender) и получателя (receiver) сообщений.
  • Общий размер (суммарно размер всех сообщений, находящихся в данный момент в очереди) очереди не превысит 5 ГБ.
  • Может потребоваться изменения шаблона взаимодействия со стандартного point-to-point на шаблон взаимодействия, предполагающий прозрачное добавление дополнительных отправителей и получателей, которые в свою очередь будут получать независимые копии сообщений отправленных в очередь. Это шаблон Pub\Sub, который поддерживается (Sevice Bus.
  • Требуется гарантированное соблюдение принципа доставки At-Most-Once.
  • Необходимо иметь возможность извлекать и отправлять сообщения пакетами (batch).