Лекція 16. Windows Azure Queue: приклади використання, REST - запити
Приклади використання
Розглянемо умовний приклад, який демонструє логіку використання Azure Queue в додатку (рис. 22.1):
Рис. 22.1.
Постачальники та клієнти обмінюються інформацією за допомогою черги повідомлень. Постачальники розміщують повідомлення в черзі, клієнти - їх обробляють.
1. Клієнт 1 забирає з черги повідомлення. Йому повертається Повідомлення 1, при цьому воно стає невидимим в черзі на величину часу рівну значенню VisibilityTimeout.
2. Клієнт 2 забирає повідомлення з черги, при цьому Повідомлення 1 все ще невидимо. Таким образів Клієнту повернеться Повідомлення 2.
3. Після закінчення обробки повідомлення Клієнт 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=PRValue&timeout=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. Насправді, все виглядає досить просто: програма запитує повідомлення з черги і вказує період очікування, що визначає скільки часу ці повідомлення не будуть доступні для інших клієнтів. У разі успішної обробки повідомлення, додаток видаляє його з черги. У разі збою, або генерації виключення повідомлення повертається в чергу для подальшої обробки і стає видимим для інших клієнтів.
Важливо проектувати систему таким чином, щоб одне повідомлення з черги могло бути оброблено кілька разів без неузгодженості стану програми, навіть в разі, якщо повідомлення обробляється різними робочими ролями.
Список матеріалів для самостійного вивчення
Windows Azure Queue
1. http://msdn.microsoft.com/ru-ru/library/ee872424.aspx
Архітектура Windows Azure Queue
1. http://mscerts.net/windows/windows%20azure%20%20%20queue%20service%20architecture.aspx
Робота з чергами
1. http://blogs.infinite-x.net/2010/01/12/working-with-windows-azure-queues/
Видалення повідомлень
1. http://blog.smarx.com/posts/deleting-windows-azure-queue-messages-handling-exceptions
(Для ознайомлення з повним текстом статті необхідно залогінитись)