Windows Azure Queue: примеры использования, REST - запросы

Показывать лекцию целиком

Примеры использования

Рассмотрим условный пример, демонстрирующий логику использования Azure Queue в приложении (рис. 22.1):

(рис 22.1)

Поставщики и клиенты обмениваются информацией посредством очереди сообщений. Поставщики размещают сообщения в очереди, клиенты - их обрабатывают.

Клиент 1 забирает из очереди сообщение. Ему возвращается Сообщение 1, при этом оно становится невидимым в очереди на величину времени равную значению VisibilityTimeout.

Клиент 2 забирает сообщение из очереди, при этом Сообщение 1 все еще невидимо. Таким образов Клиенту вернется Сообщение 2.

По завершении обработки сообщения Клиент 2 удаляет его из очередь.

Отметим, что в случае, если Клиент 2 удалит Сообщение 2, а Клиент 1 не сможет удалить Сообщение 1, то последующие запросы сообщений из очереди вернут Сообщение 1. Таким образом, любое сообщение в очереди будет гарантировано обработано хотя бы единожды.

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

Рассмотрим некоторые примеры использования REST - запросов Windows Azure Queue. Учетная запись пользователя будет обозначена, как <account>, имя очереди - <AzureQueue>, само сообщение - <message>

Постановка в очередь

Следующий пример REST - запроса добавит сообщение в очередь, при помощи HTTP - метода PUT. Поясним некоторые моменты: параметр "messagettl" является необязательным и задает время жизни сообщения в секундах до семи дней, что является также сроком жизни по - умолчанию. Параметр Content-MD5 может быть задан для защиты от ошибок передачи по сети и обеспечения целостности. Параметр Content-Length (Длина содержимого) определяет размер содержимого сообщения.

PUT  <ref src="http://<account>.queue.core.windows.net/
<AzureQueue>/messages? messagettl=3600HTTP/1.1" 
type="url"/> Content-Length: 3900Content-MD5: 
HUXZLQLMuI/KZ5KDcJPcOA== Authorization: SharedKey <account>:<key> 
x-ms-date:  Thu, 10 May 14:05:56 GMT <mesage>

Извлечение сообщения

Следующий пример REST - запроса извлечет сообщение из очереди, при помощи HTTP - метода GET. Поясним некоторые моменты: "numofmessages" - число сообщение, которое должно быть извлечено (до 32х, по умолчанию только 1); " visibilitytimeout" - определяет время в секундах, которое сообщение будет оставаться невидимым, после его извлечения (от 30секунд до 2 часов, по умолчанию - 30 секунд).

GET http://<account>.queue.core.windows.net/<AzureQueue>
/messages?numofmessages=1 visibilitytimeout=100HTTP/1.1Authorization: 
SharedKey  <account>:<key>x-ms-date: Thu, 10 May 14:05: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: 2<requestID>
Date: Thu, 10 May 14:05:56 GMT

<?xml version="1.0" encoding="utf-8"?>
<QueueMessagesList>
  <QueueMessage>
    <MessageId>MessageID</MessageId>
    <InsertionTime>...</InsertionTime>
    <ExpirationTime>...</ExpirationTime>
    <PopReceipt> PRValue</PopReceipt>
    <TimeNextVisible>...</TimeNextVisible>
    <MessageText>MessageText</MessageText>
  </QueueMessage>
</QueueMessagesList>

Следует пояснить тег <PopReceipt> его значение идентифицирует полученное сообщение, в частности это значение может быть использовано для удаления сообщения.

Удаление сообщения

Следующий пример REST - запроса извлечет сообщение из очереди, при помощи HTTP - метода DELETE. Параметр " popreceipt" определяет сообщение, которое должно быть удалено, его значение получено при помощи запроса на извлечение сообщения.

DELETE /<account>/<AzureQueue>/messages/MessageID?popreceipt=PRValuetimeout=30HTTP/1.1
Content-Type: binary/octet-streamx-ms-date: Thu, 10 May 15:02:04 GMT Authorization: SharedKey <account>:<key>

Особенности обмена сообщениями Windows Azure Queuе

Подведем краткий итог и обратим внимание на основные особенности очередей и процесса обмена сообщениями Azure Queue.

При работе с " облаком", необходимо понимать, что физически между различными частями данных вашего приложения могут быть многие десятки и сотни километров. Это касается не только данных, но и рабочих ролей, обрабатывающих эти данные, одна из которых может располагаться на Дальнем Востоке, другая - в Москове. И адаптация к данной особенности - одна из основных проблем разработчиков.

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

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