4

Windows Azure でのジョブ処理の実装に成功した設計は?

要件：

  1. ジョブをキューにプッシュする機能。
  2. N 個のワーカーがキューからジョブを消費して処理できます。
  3. ジョブの呼び出し元は、完了したジョブのアラート (ポーリングではなくプッシュ) を受け取ることができる必要があります。

これまでの研究:

  1. Azure サービス バス キューを使用して "ジョブ" キューを作成します( http://blogs.msdn.com/b/appfabric/archive/2011/05/17/an-introduction-to-service-bus-queues.aspx ) 。
  2. Web フロントエンドはジョブをキューにプッシュし、ワーカーはジョブの準備ができるまでReceive() を無期限にブロックします ( http://msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.aspxを参照)。 (API 呼び出しのトランザクション コストが原因でコストがかかる「null」ロング ポーリングを回避するため)

ジョブ完了の通知に関して:

  1. ジョブが完了したときに警告を発する明らかな機能はありません。Service Bus のトピック/サブスクリプション ( https://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-topics/ ) を活用して、発信者に「サブスクライブ」させることができると考えました。ただし、「ジョブ終了通知」トピック:
    • 複数の「サブスクリプション」エントリを作成しない限り、同じトピックに複数回サブスクライブすることはできないようです (これはスケーリングされません)。
    • 各ジョブ ID の「サブスクリプション」を作成し、そのサブスクリプションで (I/O 完了ポートを使用して) Receive() API 呼び出しで呼び出し元をブロックしない限り、ジョブがいつ発生したかについてのリアルタイム通知を取得できません処理されました。

この種のジョブ システム (リアルタイム、低レイテンシ、呼び出し元への完了通知付き) を実装した経験のある人はいますか?

ありがとう

4

1 に答える 1

2

実際には、キューはプッシュで待機しません。キューに関する全体的な考え方は、受信者がメッセージをリアルタイムで受信する必要がなく、メッセージを定期的にチェックしたいということです。リアルタイム通信が必要な場合は、受信側で HTTP/TCP リスナーを作成し、送信側に HTTP/TCP リクエストを発行させることができます。

したがって、1 つのアプローチは、内部エンドポイントを使用して、Web ロールで Web サービスを作成することです。キューを使用して、メッセージと共にサービスのアドレスを worker ロールに送信します。ジョブが完了すると、ワーカー ロールはサービスを呼び出して、ジョブが完了したことを Web ロールに通知します。

このアプローチは問題ありませんが、あまり価値がありません。サーバーはブラウザーに通知できないため、UI に何かを表示することはできません (Web ソケットを実装しない限り)。そのため、ブラウザ クライアントで通知を表示する場合は、プル ソリューションを使用することをお勧めします (Web ソケットを実装していない場合)。リッチ クライアントを使用している場合は、クライアント マシンで Web サービスをホストし、worker ロールがサービスを呼び出してクライアントに通知できるようにします。

よろしくお願いします、

明徐。

于 2012-06-18T12:12:46.410 に答える