突然の障害が発生した場合に備えて、Azure ロールでデータを再処理する必要があります。次のオプションを検討します。
処理するデータのブロックごとに、データベース テーブルの行があり、「処理ノードからの最後の ping の時間」を意味する列を追加できます。したがって、ノードが処理のためにデータブロックを取得すると、「処理中」状態とその時間が「現在の時間」に設定され、その時間を1分ごとに更新するのはノードの責任です。次に、定期的に一部のノードが「処理状態と ping 時間が 10 分を超えるすべてのブロック」を要求し、それらのブロックを放棄されたと見なし、何らかの形で再処理のためにキューに入れます。
1 つ、非常に深刻な懸念事項があります。上記のアプローチでは、ノードが多かれ少なかれ同じ時間を持っている必要があります。すべての Azure ノードが妥当な精度 (数秒など) で同じ時間を持っていることに依存できますか?
ここでの答えは、時間ベースの同期を使用しないことです (ただし、使用する場合は必ず UTCNow を使用してください) が、クロックが同期されているという保証はどこにもまだありません。また、あるべきではありません。
あなたが説明している問題については、キューベースのシステムが答えです。私はそれについて多くのことを言及してきましたが、またそれを行う予定ですが、私のブログ投稿でキューベースのシステムのいくつかの利点について説明しました。
アイデアは次のとおりです。
あなたのアプローチでは、データ項目を監視できるトピックとサブスクリプションも使用できるため、AppFabric Queues を使用します。私のブログ投稿の例は、この正確なシナリオをカバーしています。唯一の違いは、worker ロールを持つ代わりに、Web アプリケーションからキューをポーリングすることです。しかし、コンセプトは同じです。
処理時間が 2 時間未満の場合は、通常、キューのセマンティクス (可視性タイムアウト) に依存できます。データが BLOB ストレージに保存されている場合、作業対象の BLOB の名前を含むキュー メッセージをワーカーにポップさせ、メッセージに適切な可視性タイムアウトを設定することができます (今日は最大 2 時間)。作業が完了すると、キュー メッセージを削除できます。失敗した場合、削除は呼び出されず、可視性タイムアウトの後、再処理のためにキューに再表示されます。これが、作業を冪等にしたい理由です。
2 時間以上かかる処理については、一般的に、ワーカーが Windows Azure BLOB ストレージの組み込みリース機能を使用して、基になる BLOB データ (可能であればダミー BLOB) をリースするリース戦略をお勧めします。ワーカーがファイルを取得しようとすると、ファイルをリースしようとします。既にリースされているファイルは、現在そのファイルを処理している worker ロールを示しています。障害が発生した場合、リースは中断され、別のインスタンスによってリース可能になります。リースは約 1 分ごとに更新する必要がありますが、無期限に保持できます。
もちろん、処理するデータは Blob Storage に保持していますよね? :)
既に示したように、VM ノード間で同期された時刻に依存するべきではありません。何らかの理由で日時を保存する場合は、UTC を使用しないと後で後悔します。
リモートデスクトップをロールインスタンスに移動し、（a）タイムゾーン（UTCだと思います）、および（b）日付と時刻の設定でインターネット時刻が有効になっていることを確認します。もしそうなら、あなたはそれらがほんの数ミリ秒離れていることに頼ることができます。（これは、代わりにメッセージキューを使用するという提案が機能しないということではありませんが、おそらくそれらはあなたのニーズに合わないでしょう。）
キュー ストレージを使用して、これを別の方法で試してみます。データのブロックをタイムアウト付きのキューにポップする場合は、処理ノード (ワーカー ロール?) にこのデータをキューからプルさせます。
処理ノードがエントリをキューから削除しない場合、データがキューからポップされた後、タイムアウト期間後に処理のためにキューに再表示されます。