8

わかりました。メッセージ キューイングに興味があります。私はすでにこの主題について多くの研究を行ってきました. 「windows azure のプログラミング」(Azure キューについて) を読んだり、Azure サービス バスに関するチュートリアルや情報をたくさん読んだり、メッセージング パターンに関するチャネル 9 のビデオを見たりしました。

しかし、私が理解していないのは、これを実際のシナリオでどのように使用するのでしょうか? すべての例は、単一の文字列またはいくつかのデータを含むオブジェクトをキューに入れ、「反対側」のキューからそれを読み取ります。しかし、そのデータをどう処理すればよいか、どうすればわかりますか? たとえば、Customer、Order、および Address をデータベースに保存しようとすると、これら 3 つのオブジェクトをキューに入れ、反対側で読み取り、データベースに入れます。この種のオブジェクトをどう処理すればよいかを知るにはどうすればよいですか?

私が持っているいくつかの質問：

  1. キューに入れるデータの種類。コマンドは、読み取り時に実行されるため、キュー内のすべてが同じインターフェイスを持ち、オブジェクト自体が何をすべきかを判断しますか?
  2. どのレイヤー間でキューを使用しますか? 私はサービス層のキューに物を入れ (検証された後)、データベースに入れることができるようにデータ アクセス層でそれを読み取ることを考えていました。
  3. 何列に並べばいいですか？接続したいレイヤー間に1つのキューだけですか、それともレイヤー間に複数のキューがありますか?
  4. この形式の疎結合により、後で処理できるようにリクエストをキューに入れることができます (たとえば、データベースを再起動する場合)。それは素晴らしいことですが、データを書き込む代わりに読み取りたい場合はどうすればよいでしょうか? 次に、データベースがオンラインになっている必要があります。また、キューを介してデータを読み取る必要がありますか?それとも、サービス レイヤーがデータ アクセス レイヤーからデータをプルしてプレゼンテーション レイヤーに渡すだけでよいでしょうか?

頭の中をぐるぐる回っていた質問のほとんどがそれだったと思います。誰かが私のためにこれを解決できることを願っています。

4

3 に答える 3

7

最も単純な例では、実行したいアクションをキューにシリアライズしてから、シリアライズされた引数のバージョンを想像してください。

Q:Delete: User 5

Worker ロールはそれを読み取って、それに応じて動作できるため、これは問題ありません。この例では、キューイングにおそらく削除と同じくらいの時間がかかったので、大きなボーナスには思えませんが、すべてのユーザーに対して BI を実行したい場合はどうすればよいでしょうか? 同期要求が処理を実行するのを待っている間、Web ページまたはアプリケーションが更新されることはありません。しかし、そのリクエストをキューにプッシュした場合:

Q:RunSome2HourProcess: User *

これで、操作をキューに入れたことに戻り、楽しい道を進むことができます。その間、キューからプルしているサーバーは余暇に処理できます。

さらに、これにより、より優れたスケールのシナリオが可能になります。その最後のメッセージが分割された場合はどうなりますか? したがって、すべてのユーザーを行うのではなく、次のようなことを行いました。

QRunSome2HourProcess: User A*-M*

QRunSome2HourProcess: User N*-Z*

2 つの Azure ワーカー ロールが負荷を分割し、情報を並行して処理します。

再試行、ワークフロー、役割間の非同期通信などに関するシナリオも多数ありますが、適切なシナリオでキューイングが有効である理由がいくつかわかります。

したがって、これらの例では: 1. アクションと識別子/クエリをキューに入れられたアイテムに入れました。キューからポーリングする worker ロールは、その処理方法を知っています。

  1. サービス層と処理層の間でキューを使用できます。処理レイヤー間でキューを使用できます。同じレイヤー内でキューを使用できます。空は限界です

  2. 私は通常、操作ごとに 1 つのキューを作成しました。したがって、上記の例では、Run2HourProcess キューがあり、それにパラメーターを書き込むだけです。また、他のプロセス タイプ用に新しいキューを作成します。しかし、それらは非常に柔軟であるため、開発者次第です。

  3. 読み取りに時間がかかる場合 (つまり、サンプルのサムネイル生成の例、または遅いデータ処理の結果) でない限り、データベースにアクセスするのは同じくらい高速です。

于 2012-04-04T22:34:22.997 に答える
2
  1. まあ、そこに好きなものを入れることができます。これは単なるメッセージなので、レイヤーが同意できるものは何でも機能します。メールを送信するタイミング、ビデオを処理する必要があるタイミングなどを示すメッセージを挿入します。
  2. ユーザー向けのリアルタイム プロセス (Web サーバーなど) とバックグラウンド処理の間のキューイングと同様に、レイヤー間のキューイングについては必ずしも考える必要はありません。キューイングを使用して、ユーザーが待機している間に Web ロールに時間を取られたくないことを行います。
  3. 本当に好きなだけ作れます。キュー メッセージにメッセージの意味を示すフィールドがある場合、仮説としてすべてを 1 つのキューに入れることができますが、必ずしもそれをお勧めするわけではありません。約半ダースのキューがあります。1 つは通知の送信用、もう 1 つはビデオ処理用、もう 1 つはレポート生成リクエスト用などです。
  4. データの保存と取得にキューを使用することは絶対にありません。TCPを使用してデータを保存しようとするなど、その仕事には間違ったツールです。

単一のワーカー インスタンス (つまり、VM) は、必要な数のキューを読み取ることができることに注意してください。そのようにコードを書くだけです。トラフィックがあまりないキューがたくさんある場合、これはコストを抑える合理的な方法です。もう 1 つの方法は、複数のメッセージ タイプを 1 つのキューに結合することです。そうすれば、メッセージを探す場所が 1 か所だけになります。

または、ワークを均等に分散させるために、多くのワーカーが同じキューから読み取るようにすることもできます。

于 2012-04-05T18:12:30.693 に答える
0

Robが言及していることに加えて、メッセージキューは、空きワーカーが利用可能になるまで（キューで）待機できるトラフィックのバーストを処理するためにも使用されます。

Azure Service Bus、キュー、およびトピックは、同じことを実現するために、内部でメッセージキューを活用していると思います。また、AppFabricでホストされているWorkflowFoundationでも同じことができる可能性があるというヒントが表示されています。

于 2012-04-05T16:42:22.300 に答える