Какие предположения я могу сделать относительно глобального времени в Azure?

Question

Я хочу, чтобы моя роль Azure обрабатывала данные в случае внезапных сбоев . Я рассматриваю следующий вариант.

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

У меня есть одно очень серьезное беспокойство. Вышеупомянутый подход требует, чтобы узлы имели более или менее одинаковое время. Могу ли я рассчитывать на то, что все узлы Azure имеют одинаковое время с некоторой разумной точностью (скажем, несколько секунд)?

Answer 1

Ответ здесь не в том, чтобы использовать синхронизацию на основе времени (если вы, тем не менее, убедитесь, что вы используете UTCNow), но нигде не гарантируется, что часы синхронизируются.И не должно быть.

Для проблемы, которую вы описываете система на основе очереди является ответом.Я много ссылался на него, и сделаю это снова, но я объяснил некоторые преимущества систем на основе очередей в своем блоге .

Идея заключается в следующем:

1. Вы помещаете рабочий элемент в очередь
2. Ваша рабочая роль (одна или несколько из них) просматривает и блокирует сообщение
3. Вы пытаетесь обработать сообщение, если вам это удастся, вы удаляете сообщение из очереди,
4. , если нет, вы позволяете ему оставаться там, где оно

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

Answer 2

Для обработки менее 2 часов обычно можно использовать семантику очереди (тайм-аут видимости). Если у вас есть данные, хранящиеся в хранилище больших двоичных объектов, вы можете попросить рабочего выдвинуть сообщение очереди, содержащее имя большого двоичного объекта, для работы с ним и установить разумное время ожидания видимости для сообщения (до 2 часов сегодня). Как только он завершит работу, он может удалить сообщение очереди. Если происходит сбой, удаление никогда не вызывается, и после истечения времени ожидания видимости оно снова появится в очереди для повторной обработки. Вот почему вы хотите, чтобы ваша работа была идемпотентной, кстати.

Для обработки, которая длится более двух часов, я обычно рекомендую стратегию лизинга, при которой работник сдает в аренду данные базового большого двоичного объекта (если это возможно, или фиктивный большой двоичный объект в противном случае), используя функциональность внутренней аренды в хранилище больших двоичных объектов Windows Azure. Когда работник отправляется на получение файла, он пытается взять его в аренду. Файл, который уже сдан в аренду, указывает на рабочую роль, обрабатывающую его в данный момент. Если произойдет сбой, аренда будет нарушена и станет доступной для аренды другим экземпляром. Аренда должна продлеваться каждую минуту или около того, но она может быть продлена на неопределенный срок.

Конечно, вы храните данные для обработки в хранилище больших двоичных объектов, верно? :)

Как уже указывалось, вы не должны полагаться на синхронизированное время между узлами ВМ. Если вы храните время по какой-либо причине - используйте UTC, или вы пожалеете позже.

Answer 3

Удаленный рабочий стол в роли экземпляра и проверьте (а) часовой пояс (я думаю, UTC), и (б), что Интернет время включено в настройках даты и времени.Если это так, то вы можете положиться на то, что они находятся на расстоянии не более нескольких мс.(Это не означает, что предложения использовать очередь сообщений вместо этого не будут работать, но, возможно, они не соответствуют вашим потребностям.)

Answer 4

Я бы попробовал это по-другому, используя хранилище очереди. Если вы помещаете свой блок данных в очередь с тайм-аутом, тогда ваши обрабатывающие узлы (рабочие роли?) Извлекают эти данные из очереди.

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