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

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

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

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

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

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

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

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

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

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

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

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

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

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