Сценарий поставщик-потребитель 8 2Примеры rest-запросов 8 1rest-запрос PutMessage 9 2rest-запрос GetMessages 9 3rest-запрос DeleteMessage 11 6Лучшие практики 11 1Повторные запросы и ошибки «Connection closed by Host»




Скачать 220.62 Kb.
Дата 27.08.2016
Размер 220.62 Kb.


Windows Azure Queue

Декабрь, 2008


Содержание


1Введение 1

2Создание приложений в облаке с использованием Azure Queue 2

3Модель данных 5

4Интерфейс REST очереди 6

5Пример использования очереди 8

5.1Сценарий поставщик-потребитель 8

5.2Примеры REST-запросов 8

5.2.1REST-запрос PutMessage 9

5.2.2REST-запрос GetMessages 9

5.2.3REST-запрос DeleteMessage 11

6Лучшие практики 11

6.1Повторные запросы и ошибки «Connection closed by Host» 11

6.2Настройка приложения на случай многократного получения ошибок превышения времени ожидания 12

6.3Обработка ошибок и составление отчетов 12

6.4Выбор времени невидимости для GetMessage 12

6.5Удаление сообщения из очереди 14

6.6Настройка рабочих ролей на основании длины очереди 14

6.7Использование двоичного формата в сообщениях 14





1Введение


Windows Azure является основой платформы Cloud Platform компании Microsoft. Это «операционная система для облака», которая обеспечивает стандартные блоки для написания масштабируемых сервисов высокой надежности. Windows Azure предоставляет:

  • Виртуализированные вычисления

  • Масштабируемое хранилище

  • Автоматизированное управление

  • Насыщенный SDK

Хранилище Windows Azure Storage обеспечивает разработчикам возможность хранения данных в облаке. Приложение может выполнять доступ к своим данным в любой момент времени из любой точки планеты, хранить любой объем данных и как угодно долго. При этом данные гарантированно не будут повреждены и утеряны. Windows Azure Storage предлагает богатый набор абстракций данных:



  • Windows Azure Blob – обеспечивает хранилище больших элементов данных.

  • Windows Azure Table – обеспечивает структурированное хранилище состояний сервиса.

  • Windows Azure Queue – обеспечивает диспетчеризацию асинхронных заданий для реализации обмена данными между сервисами.

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


2Создание приложений в облаке с использованием Azure Queue


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


Рабочая роль

Рабочая роль

Рабочая роль

Веб роль

Веб роль
Очередь запросов


Windows Azure Cloud





Хранилище таблиц

Хранилище Blob
Рис. . Построение приложений для облака с использованием 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), что обеспечивает сохранность данных при сбоях компонентов. Таким образом, приложение может переживать сбои без потери надежности.


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


3Модель данных


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


  • Учетная запись хранилища – Любой доступ к Windows Azure Storage осуществляется через учетную запись хранилища.

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

    • Учетная запись может иметь множество очередей.

  • Очередь – Очередь содержит множество сообщений. Область действия имени очереди ограничена учетной записью.

    1. Количество сообщений в очереди не ограничено.

    2. Сообщение хранится максимум неделю. Система удаляет сообщения, поступившие более недели назад, в процессе сборки мусора.

    3. С очередями могут быть ассоциированы метаданные. Метаданные представляются в форме пар , их размер может составлять максимум 8KБ на очередь.

  • Сообщения – Сообщения хранятся в очередях. Каждое сообщение может быть размером не более 8КБ. Для хранения данных большего размера используются хранилища Azure Blob или Azure Table, а в сообщении указывается имя большого двоичного объекта/сущности. Обратите внимание, что когда сообщение помещается в хранилище, его данные могут быть двоичными. Но при извлечении сообщений из хранилища ответ формируется в формате XML, и данные сообщения возвращаются base64-кодированными. Сообщения могут возвращаться из очереди в любом порядке, и сообщение может быть возвращено несколько раз. Рассмотрим некоторые параметры, используемые Azure Queue Service:

  1. MessageID: Значение GUID, которое идентифицирует сообщение в очереди.

  2. VisibilityTimeout: Целое значение, определяющее время ожидания видимости сообщения в секундах. Максимальное значение – 2 часа. Значение по умолчанию – 30 секунд.

  3. PopReceipt: Строка, возвращаемая для каждого извлеченного сообщения. Эта строка, вместе с MessageID, необходима для удаления сообщения из очереди (Queue). Данный параметр следует рассматривать как непрозрачный, поскольку в будущем его формат и содержимое могут быть изменены.

  4. MessageTTL: Определяет срок жизни (time-to-live, TTL) сообщения в секундах. Максимально допустимый срок жизни – 7 дней. Если этот параметр опущен, срок жизни по умолчанию – 7 дней. Если в течение срока жизни сообщение не будет удалено из очереди, оно будет удалено системой хранения в процессе сборки мусора.

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


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

4Интерфейс REST очереди


Любой доступ к 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://.queue.core.windows.net/


К командам 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:

http://.queue.core.windows.net//messages


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

5Пример использования очереди

5.1Сценарий поставщик-потребитель


На следующем рисунке представлен пример, иллюстрирующий семантику Windows Azure Queue.



Producers

Поставщики

Consumers

Потребители

Рис.  Пример использования очереди

В этом примере поставщики (P1 и P2) и потребители (C1 и C2) обмениваются информацией через представленную выше очередь. Поставщики формируют рабочие элементы и помещают их в виде сообщений в очередь. Потребители изымают сообщения/рабочие элементы из очереди и обрабатывают их. Может существовать множество поставщиков и множество потребителей. Рассмотрим последовательность действий:



  1. C1 извлекает сообщение из очереди. Эта операция возвращает сообщение 1 и делает его невидимым в очереди на 30 секунд (принимаем в данном примере, что используется VisibilityTimeout по умолчанию, что составляет 30 секунд).

  2. Затем появляется C2 и извлекает из очереди другое сообщение. Поскольку сообщение 1 по-прежнему невидимое, эта операция не увидит сообщения 1 и возвратит C2 сообщение 2.

  3. По завершении обработки сообщения 2 C2 вызывает Delete, чтобы удалить сообщение 2 из очереди.

  4. Теперь представим, что C1 дает сбой в ходе обработки сообщения 1, таким образом, C1 не удаляет это сообщение из очереди.

  5. По истечении времени VisibilityTimeout для сообщения 1, оно опять появляется в очереди.

  6. После того, как сообщение 1 повторно появилось в очереди, оно может быть извлечено последующим вызовом от C2. Тогда C2 полностью обработает сообщение 1 и удалит его из очереди.

Как показано в этом примере, семантика API очереди гарантирует каждому сообщению в очереди шанс быть обработанным полностью, по крайней мере, один раз. То есть, если возникает сбой потребителя в период после извлечения им сообщения из очереди и до его удаления, сообщение опять появится в очереди по истечении времени VisibilityTimeout. Это обеспечивает возможность этому сообщению быть обработанным полностью другим потребителем.


5.2Примеры REST-запросов


В данном разделе представлены REST-запросы, используемые Windows Azure Queue. В этих примерах используется очередь «myqueue» и учетная запись «sally».

5.2.1REST-запрос PutMessage


Ниже показан пример REST-запроса для операции постановки в очередь. Заметьте, что используется HTTP-команда PUT. Задается необязательная опция «messagettl», определяющая срок жизни сообщения в секундах. Максимальный срок жизни – 7 дней. Если этот параметр опущен, значение по умолчанию – 7 дней. По истечении срока жизни сообщение будет удалено системой в процессе сборки мусора. Параметр Content-MD5 может быть задан для защиты от ошибок передачи по сети и обеспечения целостности. В данном случае, Content-MD5 – это контрольная сумма MD5 данных сообщения в запросе. Параметр Content-Length (Длина содержимого) определяет размер содержимого сообщения. Также в заголовке HTTP-запроса имеется заголовок авторизации. Обратите внимание, что данные сообщения располагаются в теле HTTP-запроса. Сообщение может храниться в текстовом или двоичном формате, но при извлечении оно возвращается base64-кодированным.
PUT http://sally.queue.core.windows.net/myqueue/messages

? messagettl=3600

HTTP/1.1 Content-Length: 3900

Content-MD5: HUXZLQLMuI/KZ5KDcJPcOA==

Authorization: SharedKey sally: F5a+dUDvef+PfMb4T8Rc2jHcwfK58KecSZY+l2naIao=

x-ms-date: Mon, 27 Oct 2008 17:00:25 GMT

……… Message Data Contents ………

5.2.2REST-запрос GetMessages


Ниже показан пример REST-запроса для операции извлечения из очереди. Заметьте, что используется HTTP-команда GET. Заданы два необязательных параметра. «numofmessages» определяет, сколько сообщений должно быть изъято из очереди; максимальное число – 32. По умолчанию извлекается одно сообщение. В примере ниже будет извлекаться по 2 сообщения. Параметр «visibilitytimeout» определяет время ожидания видимости; сообщение будет оставаться невидимым в очереди, в течение этого промежутка времени, в секундах, и вновь появится в очереди, если не будет удалено до завершения периода ожидания видимости. Максимальное значение этого времени ожидания – 2 часа, и значение по умолчанию – 30 секунд. В примере ниже время ожидания видимости задано равным 60 секундам. Также в заголовке HTTP-запроса имеется элемент авторизации. Обратите внимание, что ответ поступает в XML-формате, и данные сообщения в ответе будут base64-кодированными (в примере ниже располагаются между тегами ).
GET http://sally.queue.core.windows.net/myqueue/messages

?numofmessages=2 &visibilitytimeout=60

HTTP/1.1

Authorization: SharedKey sally: QrmowAF72IsFEs0GaNCtRU143JpkflIgRTcOdKZaYxw=

x-ms-date: Thu, 13 Nov 2008 21:37:56 GMT

Ответ на этот вызов будет аналогичен получаемому в следующем примере:


HTTP/1.1 200 OK

Transfer-Encoding: chunked

Content-Type: application/xml

Server: Queue Service Version 1.0 Microsoft-HTTPAPI/2.0

x-ms-request-id: 22fd6f9b-d638-4c30-b686-519af9c3d33d

Date: Thu, 13 Nov 2008 21:37:56 GMT








6012a834-f3cf-410f-bddd-dc29ee36de2a

Thu, 13 Nov 2008 21:38:26 GMT

Thu, 20 Nov 2008 21:36:40 GMT

AAEAAAD/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyK1JlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3cKe423ipfNapL7xPLSAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=




Thu, 13 Nov 2008 21:38:26 GMT

......




2ab3f8e5-b0f1-4641-be26-83514a4ef0a3

Thu, 13 Nov 2008 21:38:26 GMT

Thu, 20 Nov 2008 21:36:40 GMT

AAEAAAD/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyK1JlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAuX4syrxsEFGviaDUUpO8KNfNapL7xPLSAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=




Thu, 13 Nov 2008 21:38:26 GMT

.....





5.2.3REST-запрос DeleteMessage


Ниже представлен пример REST-запроса для операции удаления сообщения. В этом случае используется HTTP-команда DELETE. Параметр «popreceipt» определяет сообщение, которое должно быть удалено. «popreceipt» получается в результате предыдущей операции извлечения из очереди, как показано в примере ранее.
DELETE /sally/myqueue/messages/6012a834-f3cf-410f-bddd-dc29ee36de2a?popreceipt=AAEAAAD%2f%2f%2f%2f%2fAQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyK1JlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3%2f%2f%2f8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3cKe423ipfNapL7xPLSAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%3d&timeout=30

HTTP/1.1


Content-Type: binary/octet-stream

x-ms-date: Thu, 13 Nov 2008 21:37:56 GMT



Authorization: SharedKey sally:M/N65zg/5hjEuUS1YGCbVDHfGnI7aCAudkuTHpCDvZY=

6Лучшие практики


При проектировании приложения для использования с Windows Azure Storage важно соответствующим образом организовать обработку ошибок. В данном разделе рассматриваются вопросы, которые необходимо учесть при разработке приложения.

6.1Повторные запросы и ошибки «Connection closed by Host»


Запросы, завершившиеся ошибками превышения времени ожидания или «Connection closed by Host» (Подключение разорвано хостом), возможно, не были обработаны Windows Azure Storage. Например, если запрос PUT возвращается в результате превышения времени ожидания, последующий запрос GET может возвратить либо старое, либо обновленное значение. При получении любого из этих ответов повторите запрос с большим временем ожидания.
Более того, некоторые операции удаления, такие как очистка очереди, могут выполняться довольно длительное время. В случае невозможности завершения операции в течение заданного пользователем времени ожидания, может возникать ошибка превышения времени ожидания. В таких случаях пользователь должен повторять запрос до успешного его завершения.

6.2Настройка приложения на случай многократного получения ошибок превышения времени ожидания


Ошибки превышения времени ожидания могут возникать из-за ошибок сети между приложением и центром обработки данных. Для глобальной сети рекомендуется разбивать одну большую передачу данных на несколько меньших вызовов, и при разработке приложения проектировать обработку превышений времени ожидания/сбоев так, чтобы после возникновения ошибки оно могло возобновлять работу.
Наша система спроектирована с обеспечением возможности масштабирования и обработки больших объемов трафика. Однако чрезвычайно высокая частота запросов может стать причиной возникновения ошибок превышения времени ожидания. Сократить или устранить ошибки такого рода поможет снижение частоты запросов. Вообще говоря, пользователи редко сталкиваются с этим, однако при возникновении частых или неожиданных ошибок превышения времени ожидания обратитесь к нам через форумы Windows Azure на MSDN, где мы обсудим, как можно оптимизировать работу с Windows Azure Storage и предотвратить возникновение этих ошибок в вашем приложении.

6.3Обработка ошибок и составление отчетов


REST API выглядит как стандартный HTTP-сервер, взаимодействующий с существующими HTTP-клиентами (например, браузерами, клиентскими библиотеками HTTP, прокси, кэшами и т.д.). Чтобы гарантировать соответствующую обработку ошибок HTTP-клиентами, каждой ошибке Windows Azure Storage поставлен в соответствие определенный HTTP-код состояния.
HTTP-коды состояния менее выразительные, чем коды ошибок Windows Azure Storage, и содержат меньше информации об ошибке, тем не менее клиенты, понимающие HTTP и не понимающие ошибки Windows Azure Storage, обычно обрабатывают ошибки правильно.
Поэтому при обработке ошибок или в сообщениях об ошибках Windows Azure Storage для конечных пользователей следует использовать и HTTP-код состояния, и код ошибки Windows Azure Storage, поскольку он содержит больше сведений об ошибке. Кроме того, при отладке приложения необходимо также обращать внимание на предназначенный для пользователя элемент XML-сообщения об ошибке.

6.4Выбор времени невидимости для GetMessage


Выбор времени невидимости – это компромисс между ожидаемым временем обработки и временем восстановления приложения.
При извлечении сообщения из очереди приложение определяет время, в течение которого это сообщение будет оставаться невидимым для рабочих ролей, обрабатывающих эту очередь. Этот период должен быть достаточно длительным для завершения операции, указанной в сообщении очереди.
При слишком большом периоде ожидания в случае сбоев сильно увеличивается время, необходимое для завершения обработки сообщения. Например, если время невидимости задано равным 30 минутам, и приложение дает сбой через 10 минут после начала обработки сообщения, вторая попытка обработки этого сообщения может быть предпринята не ранее, чем через 20 минут.
Если время невидимости слишком мало, его может не хватить на обработку сообщения. Таким образом, оно станет видимым, хотя при этом будет обрабатываться одной из рабочих ролей. Это может привести к тому, что одно и то же сообщение будет обрабатываться несколькими рабочими ролями, и к невозможности удаления его из очереди (обсуждается в следующем разделе). Данная проблема может быть решена в приложении следующим образом:

  1. Если время обработки сообщения предсказуемо, время невидимости следует задавать достаточным для завершения обработки.

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

  3. Более того, операции, осуществляемые с сообщениями, должны быть гарантированно идемпотентными и возобновимыми. Методы повышения эффективности:

    1. Обработка должна прекращаться перед завершением периода невидимости, это позволит избежать многих проблем.

    2. Обработка сообщения может выполняться небольшими порциями, на обработку которых достаточно небольшого периода невидимости. В этом случае при последующем извлечении сообщения из очереди работа над ним может возобновиться с момента, на котором была прервана в предыдущий раз.

  4. Наконец, если время невидимости сообщения очень мало, слишком большое количество изъятых из очереди сообщений будут становиться видимыми до удаления. Эту проблему можно решить, используя динамическое изменение периода невидимости для новых помещаемых в очереди сообщений. Такая ситуация может быть диагностирована путем подсчета в рабочих ролях количества сбоев удаления сообщений, вызванных тем, что сообщение стало видимым. Интерфейсные веб-роли информируются о достижении некоторого порогового значения количества сбоев и могут увеличить время невидимости для новых сообщений.

6.5Удаление сообщения из очереди


После обработки сообщение должно быть удалено из очереди. Если обработка завершается в рамках времени невидимости, удаление должно быть успешным.
Сообщение удаляется только после успешной обработки. Если оно удаляется раньше, есть вероятность, что обработка сообщения не будет завершена в случае сбоя приложения.
Операция удаления может дать сбой, если период невидимости истек, и другой процесс изъял это сообщение из очереди для обработки. В этом случае приложению будет возвращен код ошибки, свидетельствующий об истечении времени невидимости (это будет HTTP-код состояния 400, и расширенный код ошибки сообщит о несоответствии «PopReceipt»). Тогда рабочая роль с устаревшим PopReceipt должна игнорировать это сообщение (поскольку оно будет снова изъято из очереди и обработано) и продолжать выполнение. Суть всего вышесказанного в том, что сообщение должно удаляться до истечения времени невидимости.

6.6Настройка рабочих ролей на основании длины очереди


Как описывалось ранее, длина очереди напрямую отражает, насколько хорошо рабочие роли справляются с общей рабочей нагрузкой. Увеличение длины очереди свидетельствует о недостаточной скорости обработки. В этом случае приложению требуется увеличить количество рабочих ролей, что обеспечит увеличение темпов выполнения работы. Если длина очереди всегда стремиться к нулю, значит, обрабатывающих мощностей больше, чем требует трафик. В этом случае приложение может сократить количество рабочих ролей и сэкономить ресурсы. Отслеживая длину очереди и настраивая количество рабочих ролей, приложения могут эффективно и равномерно масштабироваться соответственно трафику.

6.7Использование двоичного формата в сообщениях


Некоторые приложения могут хранить в сообщениях очереди двоичные данные. Для передачи двоичных данных приложения могут использовать в запросе API PutMessage. Однако данные сообщения, MessageID и PopReceipt в ответе на вызов GetMessages или PeekMessages для возвращения сообщений кодированы в формате base64. Таким образом, прежде чем использовать данные сообщения, приложению придется декодировать ответ, полученный в результате вызова GetMessages и PeekMessages.



База данных защищена авторским правом ©infoeto.ru 2022
обратиться к администрации
Как написать курсовую работу | Как написать хороший реферат
    Главная страница