9

私は、SQL Azureデータベースでデータ処理を行う、Azureでの単純な作業の役割を担っています。ワーカーは基本的に、サードパーティのデータソースから2分ごとにデータベースにデータを追加します。ロールのインスタンスが2つある場合、これは明らかに不必要に2倍になります。冗長性と99.95の稼働時間のために、2つのインスタンスが必要ですが、同じジョブを複製するだけなので、両方を同時に処理することは望ましくありません。私が見逃しているこのための標準的なパターンはありますか?データベースにフラグを設定できることは知っていますが、これを管理するための別のより簡単な、またはより良い方法があることを望んでいます。ありがとう

4

4 に答える 4

7

Mark が提案したように、Azure キューを使用してメッセージを投稿できます。Worker ロール インスタンスは、現在のメッセージを処理するときに最後に実行することとして、フォローアップ メッセージをキューに投稿できます。これは、マークがセマフォの必要性に関して提起した問題に対処する必要があります。キュー メッセージには、メッセージを処理できるときにタイムスタンプ マーキングを埋め込むことができます。新しいメッセージを作成するときは、現在の時刻に 2 分足すだけです。

そして... 明らかでない場合: ワーカー ロール インスタンスが処理を完了する前にクラッシュし、新しいキュー メッセージの再送信に失敗した場合、それは問題ありません。この場合、現在のキュー メッセージがキューに再表示されるだけで、別のインスタンスがそれを処理できるようになります。

于 2011-01-13T20:13:11.443 に答える
0

これを行うための非常に簡単な方法はありません。

マークが述べたように、セマフォを使用して、基本的に処理の開始と停止を記録できます。次に、任意の数のインスタンスを実行し、それぞれがセマフォ レコードを検査し、セマフォが許可する場合にのみ実行できます。

ただし、ここでの注意点は、インスタンスの 1 つが処理中にクラッシュし、セマフォを解放しない場合はどうなるかということです。「タイムアウト」値を実装すると、ロック解除が X 時間行われなかった場合に、他のインスタンスが処理を開始しようとします。

または、 AzureWatchなどのサード パーティの監視サービスを使用して、Azure で応答しないインスタンスを監視し、"準備完了" インスタンスの数が 1 未満の場合は新しいインスタンスを開始することができます。インスタンスは常に稼働していますが、インスタンスに障害が発生してから新しいインスタンスが開始されるまでにはわずかな時間差があります。

于 2011-01-13T20:13:30.027 に答える
0

提案されているセマフォが最適な方法ですが、ブロブ ストアで単純なタイムスタンプ ハートビートを使用することになるでしょう。

もう1つの考えは、それがどれほど必要かということです。負荷が数分間停止し続けることができる場合は、役割をリサイクルさせてください。

于 2011-01-13T23:50:07.280 に答える
0

Davidのソリューションの小さなキャッチ。キューへのメッセージの再投稿は、現在の実行の最後に行われるため、途中でマシンがクラッシュした場合、現在のメッセージは期限切れになり、キューに再表示されます。これは、メッセージが最初にピークされたものであり、キューから削除するにはデキュー操作が必要であると想定しています。デキューは、新しいメッセージをキューに挿入する前に行う必要があります。これら 2 つの操作の間にロールがクラッシュすると、システムにトークンが残らず停止します。ESB 重複チェックは実行可能なアプローチのように思えますが、バスは現在キューに存在する同一のメッセージしかチェックできないため、決定論的とは思えません。しかし、前のメッセージがキューから取り出された直後にメッセージの 1 つが届いた場合、

余裕がある場合の別の解決策は、決してデキューせず、Peek 操作を介してメッセージをリースすることです。非表示タイムアウトがワーカー ロールの処理時間を超えないようにする必要があります。最初にトークンを作成する限り、前に説明したのと同じワーカー ロールの起動戦略と ASB 重複チェックを組み合わせると機能するはずです (メッセージがキューから移動することはないため)。

于 2013-06-04T22:53:24.627 に答える