Как обнаружить непредвиденные ошибки рабочих ролей и обработать данные в этих случаях?

Question

Я хочу создать веб-сервис, размещенный в Windows Azure.Клиенты будут загружать файлы для обработки, облако будет обрабатывать эти файлы, создавать результирующие файлы, клиент будет загружать их.

Полагаю, я буду использовать веб-роли для обработки HTTP-запросов и рабочие роли для фактической обработки ичто-то вроде Azure Queue или Azure Table Storage для отслеживания запросов.Давайте представим, что это будет хранилище таблиц Azure - одна запись «запроса» на каждый загруженный пользователем файл.

Основная проблема проектирования - обработка одного файла может занять от одной секунды до десяти часов.

Итак, я ожидаю следующего случая: рабочая роль запускается, попадает в хранилище таблиц Azure, находит запрос, помеченный как «готовый к обработке», отмечает, что он «обрабатывается», начинает фактическую обработку.Обычно он обрабатывает файл и помечает запрос как «обработанный», но что, если он неожиданно умирает?

Если я не позабочусь об этом, запрос останется в состоянии «обрабатывается» навсегда.

Как отследить запросы, помеченные как «обрабатывается», но отклоненные?Какой механизм в Windows Azure был бы наиболее удобным для этого?

Answer 1

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

Как только работник завершил обработку файла, он просто копирует файл в другой контейнер в хранилище больших двоичных объектов (или удаляет его, если хотите), чтобы он не сканировался снова.

Аренда - это действительно ваш единственный ответ, пока сообщения очереди не могут быть обновлены.

edit : Я должен уточнить, что причина, по которой аренда будет работать здесь, заключается в том, что аренда должна активно поддерживаться каждые 30 секунд или около того, поэтому у вас есть очень маленькое окно, в котором вы знаете, что кто-то умер или все еще работает над этим.

Answer 2

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

Другой подход заключается в том, чтобы связать идентификацию рабочей роли с длительным процессом. Рабочие роли могут сообщать о своем состоянии здоровья, используя какое-то сердцебиение.
Если бы задания не выполнялись долго, вы могли бы пометить время начала задания вместо этого на флаге состояния и могли бы использовать механизм тайм-аута, чтобы определить, не удалось ли выполнить обработку.

Answer 3

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

Используя очереди Azure, вы устанавливаете тайм-аут, когда получаете элемент изочередь (по умолчанию: 30 секунд).Как только вы прочитаете элемент очереди (например, «файл процесса x ожидает вас в BLOB-адресе с URL-адресом y»), этот элемент очереди станет невидимым в течение указанного периода времени.Это означает, что другие экземпляры рабочих ролей не будут пытаться получить его одновременно.После завершения обработки вы просто удаляете элемент очереди.

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

Несколько вещей, о которых следует помнить:

• Элементы очереди имеют счетчик очереди.Обратите на это внимание.Как только вы нажмете определенное количество очередей для определенного элемента очереди (я предпочитаю использовать 3 раза в качестве лимита), вы должны переместить этот элемент очереди в «ядовитую очередь» или хранилище таблиц для автономной оценки - может быть что-то не так ссообщение или процесс обработки этого сообщения.
• Убедитесь, что ваша обработка идемпотентна (например, вы можете обрабатывать одно и то же сообщение несколько раз без побочных эффектов)
• Поскольку элемент очереди может стать невидимым, а затем вернуться к видимости, элементы очереди не обязательно обрабатываются в порядке FIFO.

РЕДАКТИРОВАТЬ: В соответствии с ответом Райана - Максимальное количество сообщений в очереди Azure составляет 2-перерывСообщения очереди служебной шины имеют гораздо большее время ожидания.Эта функция только что прошла CTP несколько дней назад.

Answer 4

OnStop () вашей роли может быть частью решения, но есть некоторые обстоятельства (аппаратный сбой), когда он не будет вызван.Чтобы покрыть этот случай, пусть OnStart () помечает все с тем же RoleInstanceID, что и заброшенный, потому что он не будет вызываться, если что-то еще происходит.(К счастью, Azure повторно использует свои идентификаторы экземпляров роли.)