1

私は、サーバーで処理するために、クライアントでかなりタイトなループで数千のメッセージを生成する可能性のあるアプリケーションに取り組んでいます。イベントのチェーンは次のようなものです。

  1. クライアントはアイテムを処理し、ローカル キューに入れます。
  2. ローカル キュー処理がメッセージを取得し、Web サービスを呼び出します。
  3. Web サービスは、サーバー上のサービス バスにメッセージを作成します。
  4. Service Bus はデータベースへのメッセージを処理します。

Web サービスには多くのクライアントが存在するため、すべての通信が非同期であるという考え方です。MSMQ がこれを直接実行できることは知っていますが、セキュリティなどを設定するためのその種の管理機能がクライアントに常にあるとは限りません。

私の質問は、各段階でのメッセージの粒度についてです。最も単純な方法は、クライアントで処理される各アイテムが 1 つのクライアント メッセージ/Web サービス呼び出し/サービス バス メッセージを生成することを意味します。それは問題ありませんが、可能であれば Web サービスの呼び出しをバッチ処理する方がよいことはわかっています。ただし、大粒度の Web サービス DTO とデータベースでの実行時間の短いトランザクションとの間にはトレードオフがあります。この特定のシナリオでは、すべてのアイテムが処理されるか、まったく処理されない「ビジネス トランザクション」は必要ありません。メッセージ サイズと Web サービス呼び出しの数とデータベース トランザクションの最適なバランスを実現することを目指しています。

何かアドバイス？

4

3 に答える 3

2

メッセージ キューを抽象化する

スワップ可能なメッセージ キュー バックエンドがあります。このようにして、多くのバックエンドをテストし、間違ったバックエンドを選択したり、表示される新しいバックエンドが好きになったりした場合に簡単に救済できます. メッセージングのオーバーヘッドは通常、リクエストのパッキングと処理です。さまざまなシステムが、さまざまなレベルのトラフィックとさまざまな対称性に合わせて設計されています。

基本的な機能を抽象化すると、ニーズの変化に応じてメカニズムを交換したり、より正確に評価したりできます。

アプリケーションまたはメッセージ ルートのさまざまな部分で、異なるキュー タイプからのメッセージを変換することもできます。たとえば、より高いレベルでの 1000:1/s と 10:1/s のように、受信者が処理しているため、受信者のストレスが変化します。

幸運を

于 2009-06-15T11:56:25.783 に答える
2

おしゃべりなインターフェイス (つまり、大量のメッセージ) は、着信メッセージ (およびクライアントでは応答) を正しいコードにディスパッチしてメッセージを処理するためのオーバーヘッドが高くなる傾向があります (これはメッセージごとの固定コストになります)。 . 大きなメッセージは、メッセージの処理にリソースを使用する傾向があります。

さらに、進行中の多数の Web サービス呼び出しは、多数の TCP/IP 接続を管理する必要があることを意味し、並行性の問題 (データベースでのロックを含む) が問題になる可能性があります。

しかし、メッセージの処理の詳細がなければ、オーバーヘッドが固定されているため、おしゃべりなインターフェイスに対する一般的なアドバイスを除いて、特定するのは困難です。

于 2009-06-15T11:25:51.333 に答える