1

Entity Framework（すべてAzure上）を使用してデータベースからデータを読み取るASPMVC3.0アプリケーションがあります。実行時間の長いクエリがいくつかあり（最適化が行われています）、ソリューションがスケーラブルであることを確認し、スレッドの枯渇を防ぎたいと考えています。

非同期コントローラーを調べ、I / O完了ポートを使用してクエリを実行しました（通常のEFの代わりにBeginExecuteを使用）。ただし、非同期はデバッグが難しく、コードが複雑になります。

提案された解決策は次のとおりです。

  1. Webサーバー（Webロール）は、長時間実行されるクエリを含む要求を受け取ります（顧客セグメンテーションの例）

  2. リクエスト情報を関連するパラメータとともにテーブルに入力して戻り、スレッドが他のリクエストを処理できるようにします。

  3. ページの更新が行われるたびにUIがクエリが進行中であることを示すことができるように、データベースにフラグを設定します。

  4. ワーカーロールは常にこのテーブルをクエリし、このエントリが見つかるとすぐに、長時間実行されるクエリ（顧客セグメンテーション）を処理し、元の顧客テーブルを結果で更新します。

この場合、ユーザーにステータスをすぐに戻す必要はありません。ユーザーは数分以内にもう一度チェックして、リクエストが処理されたかどうかを確認できます。テーブルの代わりにAzureキューを使用することを計画していました（ただし、Azureキューはワーカーの役割に通知できないため、dbテーブルで問題なく動作します）。これは実行可能なソリューションですか。このようにすることの落とし穴はありますか？

4

2 に答える 2

1

これは依存します。Worker ロールが重い作業を SQL データベースに委任するだけの場合、リソースとお金の無駄に思えます。非同期要求で Web ロールを使用すると、コストを削減できます。worker ロール自体で重い作業を行う必要がある場合は、適切なアプローチです。

AJAX または Web ソケットも使用できます。データベース クエリを開始し、すぐに応答を返します。クライアントは Web ロールをポーリングしてクエリが終了したかどうかを確認するか (HTTP を使用する場合)、Web ロールがクライアントに直接通知することができます (Web ソケットを使用する場合)。

于 2012-07-04T14:12:51.413 に答える
1

Windows Azure ストレージ キューは、メッセージが処理された後に通知を送信しませんが、(おそらく Windows Azure ストレージ テーブルを使用して) 自分で実装できます。キューの良いところ: キューは並行性と失敗した試行を処理します。

例: 2 つのワーカー インスタンスが同じキューからメッセージを処理している場合、キュー メッセージが読み取られるたびに、指定した時間の間、メッセージはキュー内で非表示になります。見えない間は、メッセージを読んだワーカー インスタンスだけがそれを持っています。そのインスタンスが処理を終了すると、キュー メッセージを削除する (そして通知テーブルを更新する) ことができます。失敗した場合(おそらくロール インスタンスのクラッシュが原因)、メッセージは非表示タイムアウトの期限が切れた後にキューに再表示されます。さらに一歩進んで、コードが毎回クラッシュする原因となる単なる悪いメッセージだとしましょう。メッセージを処理する前に、デキュー数を確認できます。たとえば 2 より大きい場合は、単にメッセージを配信不能テーブルに格納し、手動で検査します。

キューに関する 1 つの注意点: キュー メッセージはべき等操作である必要があります (つまり、少なくとも 1 回は処理でき、結果は毎回まったく同じ副作用を持つ必要があります)。

キューの代わりにテーブルを使用する場合は、スケーリング (テーブルを処理する複数のスレッドまたはロール インスタンス) と配信不能処理に対処する必要があります。

于 2012-07-03T12:05:48.910 に答える