Хранение и обработка данных с Windows Azure Storage и Windows Azure SQL Databases

Очереди

Механизм очередей Windows Azure Storage используется для надежного хранения и дальнейшей доставки сообщений. Очереди Windows Azure Storage являются стандартным Middleware-обеспечением, который используется для обеспечения однонаправленных коммуникаций между Web и Worker-ролями в Windows Azure Cloud Services – например, Web-роль кладёт сообщения в очередь, которую в бесконечном цикле опрашивает Worker-роль и, забрав сообщение, приступает к его обработке. Если экземпляры Worker-роли не могут забрать или обработать сообщение, оно будет храниться некоторое время в очереди.

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

В очередях хранятся сообщения. Сообщения характеризуются:

• Очередь может содержать неограниченное количество сообщений.
• Сообщения должны быть сериализуемы как XML.
• Размер ограничен 64Кб.
• Обычно используется паттерн work ticket, суть которого заключается в передаче внутри сообщения не непосредственно сущности, но ссылку на неё и метаданные, содержащие в себе указания для обработки этой сущности.
• Сборщик мусора для очереди запускается раз в неделю.

Ссылка на очередь выглядит стандартно для именования сущностей в сервисах хранилища Windows Azure:

http://<account>.queue.core.windows.net/<QueueName>

К основным операциям над очередями с использованием клиента облачных очередей CloudQueueClient относятся получение ссылки на очередь (GetQueueReference, возвращает объект CloudQueue) и получение списка очередей (ListQueues).

У объекта CloudQueue доступно несколько базовых методов по управлению очередью:

• SetMetadata: Определяет метаданные для очереди.
• FetchAttributes: Загружает метаданные и атрибуты.
• Clear: Очищает очередь.
• Create: Создает очередь. Если очередь уже существует, будет выброшено исключение.
• CreateIfNotExists: Создает очередь в том случае, если ее не существует.
• Delete: Удаляет очередь.
• Exists: Проверяет существование очереди.
• AddMessage: Добавляет сообщение в очередь.
• DeleteMessage: Удаляет сообщение из очереди.
• GetMessage: Возвращает следующее сообщение из очереди. В это время сообщение становится "невидимым" для других обработчиков.
• GetMessages: Возвращает определенное количество сообщений из очереди.
• PeekMessage: Возвращает сообщение из очереди, оставляя его видимым для других обработчиков ("подсматривает").
• PeekMessages: Возвращает определенное количество сообщений из очереди, оставляя их видимыми для других обработчиков.
• UpdateMessage: Изменяет содержимое или время видимости сообщения.
• RetrieveApproximateMessageCount: Возвращает примерное количество сообщений в очереди. Примерное по той причине, что сообщения могут быть добавлены или удалены после того, как вы отправите запрос на количество сообщений очереди.

Усеченный экспоненциальный алгоритм отката

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

while (true)
 {
     var msg = queue.GetMessage();
     if (msg != null)
          {
                 string retrievedMsg = msg.AsString;
                 //логика
                 query.DeleteMessage(msg);

                 if (gradualDecrease)
                      if (curInterval > intervalFloor) curInterval = curInterval /2;
                      else curInterval = intervalFloor;
                 else curInterval = intervalFloor;   
           }
      else
       {
            if (curInterval <intervalCeiling) curInterval = curInterval * 2;
           
       }

Долгие очереди

Очередь, собирающая сообщения в период отключённого потребителя, называется долгой. В этом случае потребитель очереди может выходить в онлайн раз в день и забирать все сообщения, затем снова отключаться. Полезно для обмена сообщениями с внешними вендорами, а также для сокращения оплаты за время выполнения сервиса (в том случае, если потребитель является, например, Worker-ролью в Windows Azure).

Разбиение процесса

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

Партиции

Windows Azure Storage использует специальное системное поле PartitionKey для того, чтобы группировать сущности в партиции. Партиции – одно из важнейших понятий на платформе Windows Azure, так как именно оно позволяет виртуально неограниченно масштабировать хранилище, логически разделяя данные на группы. Для того, чтобы лучше понимать, как работают партиции, рассмотрим принципы работы всего хранилища Windows Azure Storage. Windows Azure Storage – это система, имеющая трёхслойную архитектуру. На первом уровне находится VIP (Virtual IP), конечная точка, по которой доступна система. Далее все запросы масштабируются на три экземпляра фронтендов (FE), серверов, принимающих запросы на сущности. На данном слое происходит логика определения прав, аутентификация клиента и маршрутизация запроса на следующий уровень. Следующий уровень, уровень партиций (Partition Layer), управляется серверами партиций и мастерами партиций. Каждому серверу партиций принадлежит определённый набор партиций, за который он "ответственен" - мастер партиций также контролирует загрузку всех серверов. На этом слое происходит балансировка нагрузки между серверами партиций и партициями.

На самом низком уровне находится распределенная файловая система – Distributed File System (DFS). На этом слое хранятся данные, доступные всем серверам партиций. DFS балансирует нагрузку на систему, распределяя запросы, и состоит из множества узлов, по которым распределены наборы данных (extents), причем каждый из наборов данных назначается одному primary server (первичному серверу) и нескольким secondary server (вторичным серверам). Каждый экстент имеет данных от 100 Мб до 1 Гб, одна сущность же может быть распределена по нескольким экстентам. При операциях записи сущностей эти операции сначала обрабатываются первичным сервером (но не выполняются), после чего передаются на выполнение операции записи какому-то из вторичных серверов. Первичный сервер в данном случае выполняет роль контроллера, распределяющего операции и следящего за их выполнением. Первичный сервер не подтверждает операцию записи до тех пор, пока как минимум два вторичных сервера не сообщат об успешной записи данных в три домена обновлений и неисправностей.

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