Создание облачных приложений с использованием очереди Azure

ОЧЕРЕДЬ WINDOWS AZURE
Декабрь 2008 г.
Содержание
1
Введение ....................................................................................................................................................................................................... 1
2
Создание облачных приложений с использованием очереди Azure ........................................................................................................ 2
3
Модель данных ............................................................................................................................................................................................. 5
4
Интерфейс REST очереди.............................................................................................................................................................................. 6
5
Пример использования очереди ................................................................................................................................................................. 7
5.1
5.2
Сценарий «поставщик — получатель» ............................................................................................................................................. 7
Примеры REST-запросов
5.2.1
5.2.2
5.2.3
6
.............................................................................................................. 9
REST-запрос PutMessage
REST-запрос GetMessages
6.2
6.3
6.4
6.5
6.6
6.7
................................................................................................................... 9
REST-запрос DeleteMessage
Передовые практические методы
6.1
.................................................................................................................... 9
............................................................................................................... 11
......................................................................................................... 11
Время ожидания повторных запросов и ошибки «Connection closed by Host" (соединение прервано узлом)
Настройка приложения при многократном возникновении ошибок превышения времени ожидания
Обработка ошибок и составление отчетов
...................... 12
........................................................................................ 12
Выбор времени невидимости для команды GetMessage
Удаление сообщения из очереди
.............. 11
........................................................................ 13
.................................................................................................. 14
Настройка рабочих ролей на основании длины очереди
Использование двоичного формата в сообщениях
........................................................................ 14
............................................................................... 14
Введение
Windows Azure является основой облачной платформы Microsoft. Эта «облачная операционная
система» предоставляет разработчикам приложений основные технологические компоненты для
создания масштабируемых служб высокой доступности :




Виртуализированные вычисления
Масштабируемое хранилище
Автоматизированное управление
Обширный пакет средств разработки
1
Хранилище Windows Azure позволяет разработчикам приложений хранить данные в облаке.
Приложение получает доступ к данным в любой момент из любой точки и может хранить какой
угодно объем данных в течение неограниченного времени. При этом гарантируется, что данные
не будут повреждены или утеряны. Хранилище Windows Azure поддерживает широкий набор
абстракций данных:



Служба больших двоичных объектов Windows Azure — обеспечивает хранение больших элементов
данных.
Таблица Windows Azure — предоставляет структурированное хранилище для поддержки состояния
службы.
Очередь Windows Azure — обеспечивает диспетчеризацию асинхронных заданий и взаимодействие
между службами.
Этот документ посвящен очередям Windows Azure и методам работы с ними. Очередь Windows
Azure предоставляет надежный механизм доставки сообщений. Простой асинхронный метод
диспетчеризации заданий дает возможность подключения к различным компонентам
приложения в облаке. Очереди Windows Azure обладают высокой надежностью, постоянством и
производительностью. Их семантика гарантирует как минимум однократную обработку
сообщения. Кроме того, очередь Windows Azure имеет REST-интерфейс, что позволяет создавать
приложения на любом языке программирования и получать доступ к очереди через Интернет в
любое время из любой точки сети.
Создание облачных приложений с использованием очереди Azure
Очередь Windows Azure позволяет разделять части облачного приложения, использовать
различные технологии для создания приложений, а также масштабировать их в соответствии с
задачами обслуживания трафика.
Очередь
запросов
:
Внутренний
рабочий
Внутренний
сервер
рабочий
Внутренний
сервер
рабочий сервер
Интерфейсный
веб-сервер
Интерфейсный
веб-сервер
Хранилище
BLOB-объектов
Хранилище
таблиц
2
Рис. 1 Создание облачных приложений с использованием очереди Azure
Приведенный выше рисунок иллюстрирует простой и широко распространенный сценарий для
облачных приложений. Интерфейсная логика обработки веб-запросов размещается на вебсерверах. Бизнес-логика приложения реализуется внутренними рабочими серверами.
Интерфейсные узлы веб-серверов обмениваются информацией с внутренними рабочими узлами
при помощи набора очередей. Устойчивое состояние приложения может сохраняться в
хранилищах больших двоичных объектов и таблиц Windows Azure.
Рассмотрим в качестве примера приложение-службу сетевого размещения видео. Пользователи
могут загружать видео в это приложение. Приложение автоматически преобразовывает и
сохраняет видеофайл в различных форматах, а также индексирует данные описания для
упрощения поиска (по ключевым словам, именам актеров, режиссеров, названию и т. д.).
Такое приложение использует описанную выше архитектуру. Интерфейсные веб-серверы
реализуют уровень представления данных и обрабатывают веб-запросы пользователей.
Пользователи могут загружать видео через веб-интерфейсы. Мультимедийные видеофайлы
помещаются в хранилище больших двоичных объектов Azure. Приложение может также
обслуживать набор таблиц для учета видеофайлов и хранения поисковых индексов. Внутренние
рабочие серверы преобразуют видеофайлы в различные форматы и сохраняют их в хранилище
больших двоичных объектов Azure. Внутренние серверы также отвечают за обновление таблиц
этого приложения в хранилище таблиц. При получении запроса пользователя (например, на
загрузку видео), веб-серверы создают рабочий элемент и помещают его в очередь запросов.
Внутренние серверы извлекают эти элементы из очереди для обработки. После успешной
обработки рабочий элемент удаляется из очереди во избежание повторной обработки другим
сервером.
Благодаря применению очередей Windows Azure, такая архитектура обладает рядом
преимуществ:
1.
Масштабируемость. Приложение может легче масштабироваться в соответствии с задачами
обработки трафика. Масштабируемость дает ряд преимуществ.
Во-первых, длина очереди свидетельствует о том, насколько хорошо внутренние узлы обработки
справляются с общей рабочей нагрузкой. Увеличение длины очереди означает, что внутренние
серверы не успевают обрабатывать данные с необходимой скоростью. В этом случае приложение
может увеличить количество рабочих узлов для ускорения обработки. Если длина очереди
постоянно близка к нулю, это означает, что серверная часть приложения обладает избытком
вычислительных мощностей. В этом случае приложение может сократить количество рабочих узлов
для экономии ресурсов. Отслеживая длину очереди и настраивая количество рабочих узлов,
приложения эффективно масштабируются в соответствии с объемами трафика.
Во-вторых, применение очередей позволяет разделить приложения на части. Это облегчает
независимое масштабирование частей приложения. В этом примере интерфейсные веб-серверы и
внутренние серверы разъединены и обмениваются данными при помощи очередей. Это позволяет
использовать различное количество веб-серверов и внутренних серверов, настраивая их
3
независимо друг от друга и не оказывая влияния на логику приложения. Таким образом,
приложение может легко масштабировать критически важные компоненты, выделяя для них
дополнительные ресурсы или компьютеры.
В-третьих, применение очередей обеспечивает гибкость использования ресурсов и повышает
эффективность масштабирования. Таким образом, для рабочих элементов с разными приоритетами
или разным весом могут использоваться разные очереди, которые обрабатываются разными
пулами внутренних серверов. Приложение распределяет ресурсы (например, количество серверов)
для каждого пула, обеспечивая их эффективное использование при обработке различного трафика.
Критически важные рабочие элементы могут быть помещены в отдельную очередь и обработаны с
высоким приоритетом, не дожидаясь выполнения остальных задач. Кроме того, можно
использовать отдельную очередь для рабочих элементов, обработка которых требует значительных
ресурсов (например, преобразование видео). Для любой из этих очередей могут использоваться
разные пулы рабочих серверов. Размер каждого пула настраивается независимо, в соответствии с
получаемым трафиком.
2.
Разделение интерфейсных и внутренних ролей. Использование очередей позволяет разделить
части приложения для повышения гибкости и расширяемости. Сообщения в очереди представлены
в стандартном или расширяемом формате, таком как XML. Это обеспечивает независимость
компонентов на обоих концах очереди.
Разные части системы могут быть реализованы с использованием разных технологий и языков
программирования. Это дает максимальную гибкость. Так, один компонент очереди может быть
написан на .NET Framework, а другой — на Python.
Изменения, происходящие внутри компонента, не оказывают влияния на остальную систему.
Например, компонент может быть изменен при помощи различных технологий или языков
программирования. Это не скажется на работе системы: изменений других компонентов не
произойдет, так как использование очередей обеспечивает разделение компонентов.
Кроме того, применение очередей допускает сосуществование в системе различных реализаций
одного и того же компонента, что облегчает переход на новые технологии. В приведенном выше
примере можно постепенно отказываться от компонентов, созданных с применением устаревших
технологий, и заменять их новыми реализациями. Старая и новая реализации могут выполняться
одновременно на разных серверах и обрабатывать рабочие элементы одной очереди. Это не
влияет на работу других компонентов приложения.
3.
Всплески трафика. Очереди обеспечивают буферизацию. Это компенсирует всплески трафика и
снижает влияние на систему сбоев отдельных компонентов. В приведенном выше примере
возможно поступление большого числа запросов за короткое время. Внутренние серверы не могут
быстро обработать все запросы. В этом случае запросы не отклоняются, а буферизуются в очередь.
Внутренние серверы получают возможность обрабатывать их в нормальном темпе, постепенно
возвращаясь к обычному режиму работы. Это позволяет приложению обрабатывать
неравномерный трафик без снижения уровня доступности.
Использование очередей также снижает влияние сбоев отдельных компонентов. В приведенном
4
выше примере при сбое нескольких внутренних серверов очередь обеспечит буферизацию всех
рабочих элементов, поступивших во время простоя. Таким образом, эти элементы не будут
утрачены. После восстановления работоспособности внутренние серверы продолжат обработку
рабочих элементов из очереди и поступающих запросов. Такие сбои не оказывают влияния на
другие компоненты. Обратите внимание, что рабочие элементы, обрабатываемые серверами в
момент сбоя, также не будут утеряны. Они возвратятся в очередь по истечении времени ожидания
видимости. Этот механизм гарантирует сохранность данных при сбоях компонентов. Приложение
устойчиво к сбоям и постоянно доступно.
Таким образом, модель очереди позволяет избежать потери данных и снижения уровня
доступности даже при систематических сбоях компонентов приложения. Чтобы эта модель
работала корректно, разработчик приложения должен обеспечить идемпотентность
обработки элементов очереди рабочими серверами. Благодаря этому, прежде чем элемент
будет полностью обработан и удален из очереди, возможна его многократная частичная
обработка, прерывающаяся в результате сбоев.
Модель данных
Очередь Windows Azure основана на следующей модели данных.

Учетная запись хранилища. Доступ к хранилищу Windows Azure осуществляется через учетную
запись хранилища.
o Это высший уровень пространства имен для доступа к очередям и их сообщениям. Чтобы
использовать хранилище Windows Azure, пользователь должен создать учетную запись при
помощи веб-интерфейса портала Windows Azure. После этого пользователь получает 256разрядный секретный ключ. Этот ключ предназначен для проверки подлинности
пользователей и авторизации запросов к системе хранения. С помощью этого секретного
ключа создается подпись HMAC SHA256 для запроса. Эта подпись передается с каждым
запросом для аутентификации запросов пользователя.
o Учетная запись может иметь несколько очередей

Очередь. Очередь содержит множество сообщений. Область действия имени очереди
ограничена учетной записью.
1.
2.

Количество сообщений в очереди не ограничено.
Максимальный срок хранения сообщения — одна неделя. Система удаляет сообщения,
поступившие более недели назад.
3. Очереди могут содержать ассоциированные метаданные. Метаданные организованы в
виде пар <имя, значение>, их максимальный размер — 8 KБ на очередь.
Сообщения. Сообщения хранятся в очередях. Размер сообщения — не более 8 КБ. Для хранения
данных большего размера используются хранилища больших двоичных объектов Azure или
хранилища таблиц Azure, а в сообщении указывается имя большого двоичного объекта. Обратите
внимание: когда сообщение помещается в хранилище, оно может содержать данные в двоичной
форме. При извлечении сообщений из хранилища ответ формируется в формате XML и данные
сообщения возвращаются в кодировке base64. Сообщения могут возвращаться из очереди в
любом порядке. Одно сообщение может быть возвращено несколько раз. Рассмотрим некоторые
параметры, используемые службой очередей Azure:
5
1. MessageID — значение идентификатора GUID, отличительный признак сообщения в
очереди.
2. VisibilityTimeout — целое значение, определяющее время ожидания видимости
сообщения в секундах. Максимальное значение — 2 часа. Значение по умолчанию — 30
секунд.
3. PopReceipt — строка, возвращаемая для каждого извлеченного сообщения. Эта строка
вместе с MessageID необходима для удаления сообщения из очереди. Данный параметр
следует рассматривать как непрозрачный, так как в будущем его формат и содержимое
могут быть изменены.
4. MessageTTL — этот параметр определяет время жизни сообщения в секундах.
Максимально допустимое время жизни — 7 дней. Если этот параметр не установлен,
время жизни по умолчанию составляет 7 дней. Если в течение времени жизни сообщение
не будет удалено из очереди, оно будет уничтожено системой хранения в процессе
очистки памяти.
URI конкретной очереди структурируется следующим образом:
http://<account>.queue.core.windows.net/<QueueName>
Первая часть имени узла образована именем учетной записи хранилища, за которым следует
ключевое слово «queue». Это обеспечивает направление запроса в ту часть хранилища Windows
Azure, которая обрабатывает запросы очереди. За именем узла следует имя очереди.
Существуют ограничения именования учетных записей и очередей (подробнее об этом
рассказывается в документе Windows Azure SDK). Например, имя очереди не может содержать
символ «/».
Интерфейс REST очереди
Доступ к очереди Windows Azure осуществляется через HTTP-интерфейс REST. Поддерживаются
протоколы HTTP и HTTPS.
Пример команды HTTP/REST на уровне учетной записи:

List Queues — представляет список всех очередей для данной учетной записи.
К командам HTTP/REST на уровне очереди относятся:




Create Queue — создает очередь под данной учетной записью.
Delete Queue — удаляет указанную очередь и ее содержимое без возможности восстановления.
Set Queue Metadata — задает и обновляет определяемые пользователем метаданные очереди.
Метаданные ассоциируются с очередью в виде пар «имя — значение». Эта команда
перезаписывает все существующие метаданные, заменяя их новыми.
Get Queue Metadata — возвращает определяемые пользователем метаданные очереди, а также
примерное число сообщений в очереди.
Операции на уровне очереди могут выполняться с использованием следующего URL:
http://<account>.queue.core.windows.net/<QueueName>
6
К командам HTTP/REST для выполнения операций на уровне сообщения относятся:





PutMessage (QueueName, Message, MessageTTL) — добавляет новое сообщение в конец очереди.
MessageTTL определяет время жизни данного сообщения. Сообщение может храниться в текстовом
или двоичном формате, а возвращается в кодировке base64.
GetMessages (QueueName, NumOfMessages N, VisibilityTimeout T) — извлекает N сообщений из
начала очереди и делает их невидимыми в течение заданного параметром VisibilityTimeout
промежутка времени T. Эта операция возвратит идентификатор сообщения, полученного при
использовании команды PopReceipt. Сообщения могут возвращаться из очереди в любом
порядке. Одно сообщение может быть возвращено несколько раз.
DeleteMessage (QueueName, MessageID, PopReceipt) — удаляет сообщение, ассоциированное с
PopReceipt, возвращенным ранее вызовом GetMessage. Обратите внимание: если сообщение не
удалено, оно повторно появится в очереди по истечении времени, установленного параметром
VisibilityTimeout.
PeekMessage (QueueName, NumOfMessages N) — извлекает N сообщений из начала очереди, не
делая сообщения невидимыми. Эта операция возвратит идентификатор сообщения для каждого
полученного сообщения.
ClearQueue — удаляет все сообщения из очереди. Обратите внимание: для удаления всех
сообщений в очереди вызывающая сторона должна повторять эту операцию до тех пор, пока не
получит подтверждение об ее успешном выполнении.
Операции на уровне сообщения могут выполняться с использованием следующего URL:
http://<account>.queue.core.windows.net/<QueueName>/messages
Полное описание API REST представлено в документе Windows Azure SDK.
Пример использования очереди
Сценарий «поставщик — получатель»
На следующем рисунке представлен пример, иллюстрирующий семантику очереди Windows
Azure.
7
Поставщики
Получатели
PopRecei
pt
MessageT
TL
–
–
4
3
2
1
PopRecei
pt
MessageT
TL
–
–
Рис. 2. Пример использования очереди
В этом примере поставщики (P1 и P2) и получатели (C1 и C2) обмениваются информацией через
указанную выше очередь. Поставщики формируют рабочие элементы и помещают их в виде
сообщений в очередь. Получатели изымают сообщения или рабочие элементы из очереди и
обрабатывают их. Может существовать множество поставщиков и множество получателей.
Рассмотрим последовательность действий:
1. C1 извлекает сообщение из очереди. Эта операция возвращает сообщение 1 и делает его
невидимым в очереди на 30 секунд (предположим, что для параметра VisibilityTimeout
установлено значение по умолчанию, т. е. 30 секунд).
2. Затем C2 извлекает из очереди другое сообщение. Так как сообщение 1 по-прежнему
невидимо, эта операция возвратит C2 сообщение 2.
3. Завершив обработку сообщения 2, C2 вызывает команду Delete (удалить), чтобы удалить
сообщение 2 из очереди.
4. Теперь предположим, что у C1 происходит сбой при обработке сообщения 1.
Следовательно, C1 не удаляет это сообщение из очереди.
5. По истечении времени, установленного параметром VisibilityTimeout для сообщения 1, оно
опять появляется в очереди.
6. После того как сообщение 1 повторно появилось в очереди, оно может быть извлечено
вызовом от C2. После этого сообщение 1 будет полностью обработано и удалено из
очереди.
Как видно из примера, семантика API очереди гарантирует полную обработку каждого сообщения
в очереди (по крайней мере однократную). Если у получателя возникнет сбой после извлечения
сообщения из очереди и до его удаления, сообщение опять вернется в очередь по истечении
времени, установленного параметром VisibilityTimeout. Это позволит другому получателю
полностью обработать сообщение.
8
5.2
Примеры REST-запросов
В этом разделе представлены REST-запросы, используемые очередями Windows Azure. В
примерах используется очередь «myqueue» и учетная запись «sally».
5.2.1 REST-запрос PutMessage
Ниже показан пример REST-запроса для операции постановки в очередь. Обратите внимание, что
используется HTTP-команда PUT. Задается необязательный параметр «messagettl». Этот параметр
определяет время жизни сообщения в секундах. Максимально допустимое время жизни — 7
дней. Если этот параметр не установлен, время жизни по умолчанию составляет 7 дней. По
истечении срока жизни сообщение будет удалено системой в процессе очистки памяти. Параметр
Content-MD5 может быть задан для обеспечения целостности данных и защиты от ошибок при
передаче по сети. В данном случае параметр Content-MD5 — это контрольная сумма MD5 данных
сообщения в запросе. Параметр длины содержимого определяет размер содержимого
сообщения. Заголовок 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.2 REST-запрос GetMessages
Ниже приведен пример REST-запроса для операции извлечения из очереди. Обратите внимание,
что используется HTTP-команда GET. Заданы два необязательных параметра. «numofmessages»
определяет, сколько сообщений должно быть изъято из очереди; максимальное число — 32. По
умолчанию из очереди извлекается одно сообщение. В приведенном примере будет извлекаться
до двух сообщений. Параметр «visibilitytimeout» определяет время ожидания видимости в
секундах; сообщение будет оставаться невидимым в течение этого времени и вновь появится в
очереди, если не будет удалено до завершения периода ожидания видимости. Максимальное
значение времени ожидания — 2 часа; значение по умолчанию — 30 секунд. В приведенном
примере время ожидания видимости задано равным 60 секундам. Заголовок HTTP-запроса
содержит заголовок авторизации, как показано ниже. Обратите внимание, что ответ поступает в
XML-формате, и данные сообщения в ответе будут зашифрованы в формате base64 (в примере
ниже располагаются между тегами <MessageText> </MessageText>).
GET http://sally.queue.core.windows.net/myqueue/messages
9
?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
<?xml version="1.0" encoding="utf-8"?>
<QueueMessagesList>
<QueueMessage>
<MessageId>6012a834-f3cf-410f-bddd-dc29ee36de2a</MessageId>
<InsertionTime>Thu, 13 Nov 2008 21:38:26 GMT</InsertionTime>
<ExpirationTime>Thu, 20 Nov 2008 21:36:40 GMT</ExpirationTime>
<PopReceipt>AAEAAAD/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXI
uWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAVU
1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVl
dWVNYW5hZ2VyK1JlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYW
NraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9
nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3cKe423ipfNapL7xPLSAsAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</P
opReceipt>
<TimeNextVisible>Thu, 13 Nov 2008 21:38:26 GMT</TimeNextVisible>
<MessageText>......</MessageText>
</QueueMessage>
<QueueMessage>
<MessageId>2ab3f8e5-b0f1-4641-be26-83514a4ef0a3</MessageId>
<InsertionTime>Thu, 13 Nov 2008 21:38:26 GMT</InsertionTime>
<ExpirationTime>Thu, 20 Nov 2008 21:36:40 GMT</ExpirationTime>
<PopReceipt>AAEAAAD/////AQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2VydmljZS5RdWV1ZU1hbmFnZXI
uWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAVU
1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNYW5hZ2VyLlhBQy5SZWFsUXVl
dWVNYW5hZ2VyK1JlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2liaWxpdHlTdGFydD5rX19CYW
NraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3///8LU3lzdGVtLkd1aWQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9
nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAuX4syrxsEFGviaDUUpO8KNfNapL7xPLSAsAAAAAAAAAAAA
10
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=</Po
pReceipt>
<TimeNextVisible>Thu, 13 Nov 2008 21:38:26 GMT</TimeNextVisible>
<MessageText>.....</MessageText>
</QueueMessage>
</QueueMessagesList>
5.2.3 REST-запрос DeleteMessage
Ниже приведен пример REST-запроса для операции удаления сообщения. В этом случае
используется HTTP-команда DELETE. Параметр «popreceipt» определяет сообщение, которое
должно быть удалено. Параметр «popreceipt» извлекается в результате предыдущей операции
выведения из очереди, как было показано ранее.
DELETE /sally/myqueue/messages/6012a834-f3cf-410f-bddddc29ee36de2a?popreceipt=AAEAAAD%2f%2f%2f%2f%2fAQAAAAAAAAAMAgAAAFxOZXBob3MuUXVldWUuU2Vyd
mljZS5RdWV1ZU1hbmFnZXIuWEFDLCBWZXJzaW9uPTYuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5V
G9rZW49bnVsbAUBAAAAVU1pY3Jvc29mdC5DaXMuU2VydmljZXMuTmVwaG9zLlF1ZXVlLlNlcnZpY2UuUXVldWVNY
W5hZ2VyLlhBQy5SZWFsUXVldWVNYW5hZ2VyK1JlY2VpcHQCAAAAFjxNc2dJZD5rX19CYWNraW5nRmllbGQgPFZpc2l
iaWxpdHlTdGFydD5rX19CYWNraW5nRmllbGQDAAtTeXN0ZW0uR3VpZA0CAAAABP3%2f%2f%2f8LU3lzdGVtLkd1a
WQLAAAAAl9hAl9iAl9jAl9kAl9lAl9mAl9nAl9oAl9pAl9qAl9rAAAAAAAAAAAAAAAIBwcCAgICAgICAjSoEmDP8w9Bvd3
cKe423ipfNapL7xPLSAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAA%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 важно правильно
организовать обработку ошибок. В этом разделе рассматриваются вопросы, которые необходимо
учесть при разработке приложения.
6.1 Время ожидания повторных запросов и ошибки «Connection closed by
Host» (соединение прервано узлом)
Запросы, завершившиеся ошибками превышения времени ожидания или «Connection closed by
Host» (соединение прервано узлом), возможно, не были обработаны хранилищем Windows Azure.
Например, если запрос PUT возвращается в результате превышения времени ожидания,
последующий запрос GET возвратит либо старое, либо обновленное значение. При получении
любого из этих ответов повторите запрос с экспоненциальной выдержкой и большим временем
ожидания.
11
Некоторые операции удаления, такие как очистка очереди сообщений, требуют значительных
ресурсов и выполняются довольно долго. При невозможности завершения операции в течение
заданного пользователем времени может возникать ошибка превышения времени ожидания. В
таких случаях пользователь должен повторять запрос до его успешного выполнения.
6.2 Настройка приложения при многократном возникновении ошибок
превышения времени ожидания
Ошибки превышения времени ожидания могут возникать из-за ошибок сети между приложением
и центром обработки данных. Для глобальной сети рекомендуется разбивать операцию по
передаче большого объема данных на несколько мелких операций. Следует предусмотреть,
чтобы после обработки сбоев (превышения времени ожидания) приложение могло продолжить
работу.
Windows Azure обеспечивает масштабирование и обработку больших объемов трафика. Однако
чрезвычайно высокая частота запросов может стать причиной возникновения ошибок
превышения времени ожидания. Снижение частоты запросов позволит сократить или устранить
ошибки такого рода. Большинство пользователей редко сталкиваются с ошибками превышения
времени ожидания. Тем не менее если такие ошибки возникают часто или неожиданно —
обратитесь к нам через форумы Windows Azure на MSDN. Мы поможем вам оптимизировать
работу с хранилищем Windows Azure и предотвратить появление этих ошибок в вашем
приложении.
6.3 Обработка ошибок и составление отчетов
API REST выглядит как стандартный HTTP-сервер, взаимодействующий с HTTP-клиентами
(браузерами, клиентскими библиотеками HTTP, прокси, кэшем и т. д.). Для корректной обработки
ошибок HTTP-клиентами каждой ошибке хранилища Windows Azure поставлен в соответствие
определенный HTTP-код состояния.
HTTP-коды состояния менее выразительные, чем коды ошибок хранилища Windows Azure, и
содержат меньше информации об ошибке. Тем не менее клиенты, понимающие HTTP и не
понимающие коды ошибок хранилища Windows Azure, обычно обрабатывают ошибки правильно.
Поэтому при обработке ошибок или создании сообщений об ошибках хранилища Windows Azure
для конечных пользователей вместо HTTP-кода состояния следует использовать код ошибки
хранилища Windows Azure, так как он содержит больше сведений об ошибке. Кроме того, при
отладке приложения нужно обращать внимание на предназначенный для пользователя элемент
<ExceptionDetails> XML-сообщения об ошибке.
12
6.4 Выбор времени невидимости для команды GetMessage
Выбор времени невидимости — это компромисс между ожидаемым временем обработки и
временем восстановления приложения.
При извлечении сообщения из очереди приложение задает время, в течение которого сообщение
будет оставаться невидимым для других обработчиков этой очереди. Этот период должен быть
достаточно длительным для завершения операции, указанной в сообщении очереди.
Слишком большой период ожидания приводит к неоправданному увеличению времени,
необходимого для завершения обработки сообщения при сбоях. Например, если время
невидимости составляет 30 минут и приложение дает сбой через 10 минут после начала
обработки сообщения, вторая попытка обработки этого сообщения может быть предпринята не
ранее чем через 20 минут.
Если время невидимости слишком мало, сообщение может стать видимым, когда его обработка
еще не закончена. В результате одно и то же сообщение будет обрабатываться несколькими
процессами. Процесс, завершивший обработку, не сможет удалить сообщение из очереди. Такая
ситуация обсуждается в следующем разделе. Эта проблема может быть решена следующим
образом.
1. Если время обработки сообщения предсказуемо, время невидимости следует
задавать достаточным для завершения обработки.
2. Иногда время обработки разных типов сообщений может существенно отличаться.
В этом случае можно использовать для них разные очереди, т. е. сообщения
распределяются по очередям соответственно времени, которое необходимо для
их обработки. Для каждой очереди задается собственное значение времени
невидимости.
3. Операции обработки сообщений должны быть идемпотентными и
возобновляемыми. Методы повышения эффективности:
а) обработка должна прекращаться перед завершением периода невидимости, во
избежание дублирования операций;
б) сообщение может обрабатываться небольшими блоками с малым временем
невидимости. В этом случае при последующем извлечении сообщения из очереди
после того, как оно становится видимым, работа над ним может возобновиться с
момента, на котором была прервана в предыдущий раз.
4. Если время невидимости сообщения очень мало, слишком много изъятых из
очереди сообщений будет становиться видимыми до удаления. Может
потребоваться динамическое изменение периода невидимости для новых
помещаемых в очереди сообщений. Для этого необходимо подсчитать количество
сбоев удаления сообщений, вызванных тем, что сообщение стало видимым. Если
количество сбоев достигает порогового значения, интерфейсные веб-роли могут
увеличить время невидимости для новых сообщений, поступающих в очередь.
13
6.5 Удаление сообщения из очереди
После обработки сообщение должно быть удалено из очереди. Если обработка завершается в
рамках времени невидимости, удаление будет успешным.
Сообщение должно удаляться только после его успешной обработки. Если оно удаляется раньше,
есть вероятность, что при сбое приложения обработка сообщения не будет завершена.
Операция удаления может быть не выполнена, если период невидимости истек, и другой процесс
изъял это сообщение из очереди для обработки. В этом случае приложению будет возвращен код
ошибки, свидетельствующий об истечении времени невидимости (это будет HTTP-код состояния
400, а расширенный код ошибки сообщит о несоответствии «PopReceipt»). Тогда рабочая роль с
устаревшим PopReceipt должна игнорировать это сообщение (так как оно будет снова изъято из
очереди и обработано) и продолжать выполнение операции. Суть всего вышесказанного в том,
что сообщение должно удаляться до истечения времени невидимости.
6.6 Настройка рабочих ролей на основании длины очереди
Как было отмечено ранее, длина очереди дает представление о том, насколько хорошо
внутренние узлы обработки справляются с общей рабочей нагрузкой. Увеличение длины очереди
означает, что внутренние серверы не успевают обрабатывать данные с необходимой скоростью. В
этом случае приложение может увеличить количество рабочих узлов для ускорения обработки.
Если длина очереди постоянно близка к нулю, это означает, что серверная часть приложения
обладает избытком вычислительных мощностей. В этом случае приложение может сократить
количество рабочих узлов для экономии ресурсов. Отслеживая длину очереди и задавая
количество рабочих узлов, приложения могут эффективно масштабироваться в соответствии с
объемами трафика.
6.7 Использование двоичного формата в сообщениях
Некоторым приложениям требуется хранение двоичных данных в сообщениях очереди. Такие
приложения могут вызывать API PutMessage и отправлять бинарные данные в запросе. Однако
когда приложение вызывает GetMessages или PeekMessages для возвращения сообщений, ответ
содержит данные сообщения, MessageID и PopReceipt в кодировке base64. Таким образом,
прежде чем использовать эти сообщения, приложению придется декодировать ответ, полученный
в результате вызова GetMessages и PeekMessages.
14