Что такое хранилище очередей Azure? What is Azure Queue Storage?

Хранилище очередей Azure — это служба для хранения большого количества сообщений. Azure Queue Storage is a service for storing large numbers of messages. Доступ к сообщениям возможен из любой точки мира с помощью вызовов с проверкой подлинности по протоколу HTTP или HTTPS. You access messages from anywhere in the world via authenticated calls using HTTP or HTTPS. Максимальный размер сообщения в очереди составляет 64 КБ. A queue message can be up to 64 KB in size. Очередь может содержать миллионы сообщений вплоть до лимита всей емкости учетной записи хранения. A queue may contain millions of messages, up to the total capacity limit of a storage account. Очереди обычно используются для создания списка невыполненных заданий для асинхронной обработки. Queues are commonly used to create a backlog of work to process asynchronously.

Основные понятия службы «Хранилища очередей» Queue Storage concepts

Служба «Хранилище очередей» состоит из следующих компонентов: Queue Storage contains the following components:

Формат URL-адреса. К очереди можно обратиться, используя следующий формат URL-адреса: URL format: Queues are addressable using the following URL format:

Следующий URL-адрес позволяет обратиться к очереди на схеме: The following URL addresses a queue in the diagram:

Учетная запись хранения. Весь доступ к хранилищу Azure осуществляется с помощью учетной записи хранения. Storage account: All access to Azure Storage is done through a storage account. Сведения о емкости учетной записи хранения см. в статье о целевых показателях масштабируемости и производительности для учетных записей хранения ценовой категории «Стандартный». For information about storage account capacity, see Scalability and performance targets for standard storage accounts.

Очередь. Очередь содержит набор сообщений. Queue: A queue contains a set of messages. Имя очереди должно содержать только строчные символы. The queue name must be all lowercase. Дополнительные сведения об именовании очередей см. в статье Именование очередей и метаданных. For information on naming queues, see Naming queues and metadata.

Сообщение. Сообщение в любом формате размером до 64 КБ. Message: A message, in any format, of up to 64 KB. В версиях, предшествовавших 2017-07-29, максимальный срок жизни сообщения составлял семь дней. Before version 2017-07-29, the maximum time-to-live allowed is seven days. Начиная с версии 2017-07-29, максимальный срок жизни может быть задан любым положительным числом или значением -1, свидетельствующим о том, что срок жизни сообщения неограничен. For version 2017-07-29 or later, the maximum time-to-live can be any positive number, or -1 indicating that the message doesn’t expire. Если этот параметр не указан, срок жизни по умолчанию составляет семь дней. If this parameter is omitted, the default time-to-live is seven days.

Azure Services Platform. Часть 2

Azure Queue Services

Windows Azure Queue предоставляет надежный механизм доставки сообщений. Она предлагает простой алгоритм диспетчеризации асинхронных заданий, который обеспечивает возможность подключения к разным компонентам приложения в облаке. Очереди Windows Azure Queue характеризуются высокой надежностью, постоянством и производительностью. Текущая реализация гарантирует, по крайней мере, однократную обработку сообщения. Более того, Windows Azure Queue имеет REST- интерфейс , таким образом, приложения могут создаваться на любом языке программирования и выполнять доступ к очереди через веб в любое время из любой точки Интернета.

Рассмотрим создание приложений в облаке с использованием Azure Queue. Windows Azure Queue позволяет разделить разные части приложения в облаке, что делает возможным использование разных технологий для создания этих приложений, и их масштабирование соответственно нуждам трафика.

Приведенный выше рисунок иллюстрирует простой и распространенный сценарий для приложений в облаке. Имеется ряд веб ролей, на которых размещается интерфейсная логика обработки веб-запросов. Также существует ряд рабочих ролей, реализующих бизнес-логику приложения. Веб роли обмениваются информацией с рабочими ролями посредством наборов запросов. Устойчивое состояние приложения может сохраняться в хранилищах Windows Azure Blob и Windows Azure Table .

Рассмотрим в качестве примера приложение онлайн сервиса видеохостинга. Пользователи могут загружать видео в это приложение ; после этого приложение может автоматически преобразовывать и сохранять этот видеофайл в различных форматах мультимедиа ; кроме того, приложение автоматически индексирует данные описания видео для упрощения поиска (например, по ключевым словам описания, именам актеров, режиссеров, названию и т.д.).

Такое приложение может использовать описанную ранее архитектуру. Веб-роли реализуют уровень представления и обрабатывают веб-запросы пользователей. Пользователи могут загружать видео через веб-интерфейсы. Видео-файлы могут храниться как большие двоичные объекты в хранилище Azure Blob . Приложение может также обслуживать ряд таблиц для учета имеющихся видеофайлов и хранения индексов, используемых для поиска. Рабочие роли выполняют преобразование входящих видеофайлов в разные форматы и сохранение их в хранилище Azure Blob . Рабочие роли также отвечают за обновление таблиц этого приложения в Azure Table . При получении запроса пользователя (например, запроса на загрузку видео) веб-роли создают рабочий элемент и помещают его в очередь запросов. Рабочие роли извлекают эти рабочие элементы из очереди и обрабатывают соответствующим образом. В случае успешной обработки рабочая роль должна удалить рабочий элемент из очереди во избежание повторной его обработки другой рабочей ролью.

Благодаря применению Windows Azure Queue такая архитектура обладает рядом преимуществ:

1. Масштабируемость – Приложение может легче масштабироваться соответственно нуждам трафика. Вот преимущества, связанные с масштабированием: Во-первых, длина очереди напрямую отражает насколько хорошо рабочие роли справляются с общей рабочей нагрузкой. Увеличение очереди свидетельствует о том, что рабочие роли не могут обрабатывать данные с необходимой скоростью. В этом случае приложению может потребоваться увеличить количество рабочих ролей, чтобы обеспечить более быструю обработку. Если длина очереди неизменно остается близкой к нулю, это означает, что серверная часть приложения обладает большими вычислительными мощностями, чем требуется. В этом случае приложение может сократить количество рабочих ролей для обеспечения рационального расходования ресурсов. Отслеживая размеры очереди и настраивая количество внутренних узлов, приложения могут эффективно масштабироваться соответственно объемам трафика. Во-вторых, применение очередей позволяет разделить части приложения и выполнять их масштабирование независимо друг от друга, что намного упрощает эту задачу. В данном примере веб-роли и рабочие роли отделены друг от друга и обмениваются информацией через очереди. Это позволяет настраивать количество веб-ролей и рабочих ролей независимо друг от друга без влияния на логику приложения. Таким образом, приложение может свободно масштабировать критически важные компоненты, добавляя для них больше ресурсов/компьютеров. В-третьих, применение очередей обеспечивает гибкость для эффективного использования ресурсов в приложении, что повышает эффективность масштабирования. То есть для рабочих элементов с разными приоритетами и/или разных размеров могут использоваться разные очереди, которые будут обрабатываться разными пулами рабочих ролей. В этом случае приложение может распределять соответствующие ресурсы (например, с точки зрения количества серверов) для каждого пула, таким образом, обеспечивая эффективное использование доступных ресурсов при разных характеристиках трафика. Например, рабочие элементы, имеющие критически важное значение для всей задачи, могут быть помещены в отдельную очередь . Это обеспечит их обработку независимо от всех остальных задач. Кроме того, отдельная очередь может использоваться для рабочих элементов, обработка которых требует привлечения большого количества ресурсов (например, преобразование видео). Для каждой из этих очередей могут использоваться разные пулы рабочих ролей. Приложение может настраивать размер каждого из пулов независимо, соответственно поступающему трафику.

2. Разделение ролей — Использование очередей позволяет разделить разные части приложения, что обеспечивает существенную гибкость и расширяемость с точки зрения построения приложения. Сообщения в очереди могут быть в стандартном или расширяемом формате, таком как XML , что обеспечивает независимость компонентов на обоих концах очереди друг от друга, поскольку они могут понимать сообщения в очереди. Разные части системы могут быть реализованы с использованием разных технологий и языков программирования. Например, компонент на стороне очереди может быть написан на . NET Framework, а другой компонент – на Python . Более того, изменения, происходящие внутри компонента, не имеют никакого влияния на остальную систему. Например, компонент может быть изменен с применением совершенно другой технологии или языка программирования, при этом система будет продолжать работать точно так же, и для этого не придется изменять другие компоненты, поскольку использование очередей обеспечивает разделение компонентов. Кроме того, использование очередей делает возможным сосуществование в системе разных реализаций одного и того же компонента, т.е. приложение может свободно переходить к новым технологиям. В рассматриваемом выше примере можно постепенно уходить от компонентов, созданных с применением устаревших технологий, и заменять их новыми реализациями. Старая и новая реализации могут выполняться одновременно на разных серверах и обрабатывать рабочие элементы одной очереди. При этом другие компоненты приложения никак не будут затронуты.

3. Всплески трафика — Очереди обеспечивают буферизацию, что компенсирует всплески трафика и сокращает влияние, оказываемое сбоями отдельных компонентов. В рассматриваемом ранее примере возможны случаи поступления большого числа запросов в короткий промежуток времени. Рабочие роли не могут быстро обработать все запросы. В этом случае запросы не отклоняются, а буферизуются в очередь , и рабочие роли получают возможность обрабатывать их в собственном нормальном темпе, постепенно возвращаясь к обычному режиму работы. Это позволяет приложению обрабатывать неравномерный трафик без снижения надежности. Более того, использование очередей также снижает влияние, оказываемое сбоями отдельных компонентов. В рассматриваемом выше примере в случае сбоя нескольких рабочих ролей очередь обеспечит буферизацию всех рабочих элементов, поступивших во время простоя рабочих ролей, таким образом, эти элементы не будут утрачены. Когда рабочие роли вернуться в работу, они смогут продолжить обработку рабочих элементов из очереди и, в конце концов, вернуться к нормальному режиму обработки данных по мере их поступления. Такие сбои не оказывают никакого влияния на другие компоненты. Обратите внимание, что рабочие элементы, обрабатываемые рабочими ролями на момент их сбоя, также не будут утеряны, поскольку возвратятся в очередь по истечении времени ожидания видимости (VisibilityTimeout), что обеспечивает сохранность данных при сбоях компонентов. Таким образом, приложение может переживать сбои без потери надежности.

Итак, благодаря модели очереди приложения застрахованы от потери данных и снижения надежности даже в условиях систематических сбоев компонентов приложения. Для обеспечения корректной работы этой модели разработчик приложения должен обеспечить идемпотентность обработки рабочих элементов очереди рабочими ролями. Благодаря этому, прежде чем рабочий элемент будет полностью обработан и удален из очереди, допускаются его многократные частичные обработки, прерывающиеся в результате сбоев.

Windows Azure Queue имеет следующую модель данных .

• Учетная запись хранилища – Любой доступ к Windows Azure Storage осуществляется через учетную запись хранилища.
  • Это самый высокий уровень пространства имен для доступа к очередям и их сообщениям. Для использования Windows Azure Storage пользователь должен создать учетную запись хранилища. Выполняется это через веб-интерфейс портала Windows Azure Portal. При создании учетной записи пользователь получает 256-разрядный секретный ключ, который впоследствии используется для аутентификации запросов этого пользователя к системе хранения. В частности, с помощью этого секретного ключа создается подпись HMAC SHA256 для запроса.

  Эта подпись передается с каждым запросом данного пользователя для обеспечения аутентификации через проверку достоверности подписи HMAC.

  URI конкретной очереди структурировано следующим образом:

  Первая часть имени хоста образована именем учетной записи хранилища, за которым следует ключевое слово «queue». Это обеспечивает направление запроса в часть Windows Azure Storage , которая обрабатывает запросы очереди. За именем хоста идет имя очереди. Существуют ограничения именования учетных записей и очередей (подробнее об этом рассказывается в документе Windows Azure SDK ). Например, имя очереди не может включать символ «/».

  Любой доступ к Windows Azure Queue выполняется через HTTP — интерфейс REST. Поддерживаются как HTTP , так и HTTPS протоколы.

  К командам HTTP /REST на уровне учетной записи относятся:

  • List Queues – Представить список всех очередей данной учетной записи.

  К командам HTTP /REST на уровне очереди относятся:

  • Create Queue – Создать очередь под данной учетной записью.
  • Delete Queue – Удалить указанную очередь и ее содержимое без возможности восстановления.
  • Set Queue Metadata – Задать/обновить определяемые пользователем метаданные очереди. Метаданные ассоциированы с очередью в виде пар имя/значение. Эта команда обеспечит перезапись всех существующих метаданных новыми.
  • Get Queue Metadata – Извлечь определяемые пользователем метаданные очереди, а также примерное число сообщений в заданной очереди.

  Операции уровня очереди могут выполняться с использованием следующего URL :

  К командам HTTP /REST, поддерживаемым для реализации операций на уровне сообщения, относятся:

  • PutMessage (QueueName, Message, MessageTTL) – Добавить новое сообщение в конец очереди. MessageTTL определяет срок жизни данного сообщения. Сообщение может храниться в текстовом или двоичном формате, но возвращается base64-кодированным.
  • GetMessages (QueueName, NumOfMessages N, VisibilityTimeout T) – Извлечь N сообщений из начала очереди и сделать их невидимыми в течение заданного VisibilityTimeout промежутка времени T. Эта операция возвратит ID сообщения, возвращенного вместе с PopReceipt. Сообщения могут возвращаться из очереди в любом порядке, и сообщение может быть возвращено несколько раз.
  • DeleteMessage (QueueName, MessageID, PopReceipt) – Удалить сообщение, ассоциированное с данным PopReceipt, возвращенным ранее вызовом GetMessage. Обратите внимание, что если сообщение не будет удалено, оно повторно появится в очереди по истечении VisibilityTimeout.
  • PeekMessage (QueueName, NumOfMessages N) – Извлечь N сообщений из начала очереди, не делая сообщения невидимыми. Эта операция возвратит ID сообщения для каждого возвращенного сообщения.
  • ClearQueue – Удалить все сообщения из заданной очереди. Заметьте, что вызывающая сторона должна повторять эту операцию до тех пор, пока получает сообщения об успешном ее выполнении, это обеспечит удаление всех сообщений очереди.

  Операции уровня сообщения могут быть выполнены с использованием следующего URL :

  Полное описание API REST можно найти в документе Windows Azure SDK .