メッセージキューとサービスバスのメッセージ細分性

Question

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

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

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

私の質問は各段階でのメッセージの細分性についてです。最も簡単な方法は、クライアント上で処理される各アイテムが1つのクライアントメッセージ/ Webサービスコール/サービスバスメッセージを生成することを意味します。大丈夫ですが、大規模なWebサービスDTOとデータベースの短期間のトランザクションとの間にトレードオフがある点を除いて、可能な場合はWebサービスコールをバッチ処理するほうがよいとわかっています。この特定のシナリオでは、すべてのアイテムまたはすべてのアイテムが処理される「ビジネストランザクション」は必要ありません。メッセージサイズとWebサービスコールの数とデータベーストランザクションの最適なバランスを達成するために探しています。

アドバイスはありますか？

Answer 1

Chattyインターフェイス（つまり、たくさんのメッセージ）は、着信メッセージ（クライアント、返信）をメッセージを処理する正しいコードにディスパッチする際に大きなオーバーヘッドを持つ傾向があります1メッセージあたりのコスト）。大きなメッセージはメッセージを処理する際にリソースを使用する傾向があります。

また、多くのWebサービスコールが進行中であれば、多くのTCP/IP接続を管理し、並行処理の問題（データベースのロックを含む）が問題になる可能性があります。

メッセージの処理の細かいことがなくても、オーバーヘッドが固定されているため、チャット・インターフェイスに対する一般的なアドバイス以外には、特定するのは難しいです。

Answer 2

最初に測定し、後で最適化します。最も単純なソリューションが許容できないほど高い負荷を発生させることを示す包絡線の見積もりを作成できない限り、試してみて、良い監視測定値を確立し、それがどのように実行され、スケールするかを見てください。 その後、は、どのくらいバッチするか、どこで考えるかを開始します。

このアプローチは、もちろん、あなたが並列に複数のWSのバージョンをサポートし、再設計されていない可能性があり、クライアントに対処するためのバージョニングアプローチを必要とするので、配備後にWebサービスのインターフェイスを変更できるようにする必要があります。しかし、バージョン管理について考えることは、ほとんどの場合、常に最適ではないインターフェイスでトラップします。

Answer 3

抽象メッセージキュー

とスワップ可能なメッセージキューのバックエンドを持っています。この方法で多くのバックエンドを手に入れて、間違ったものを選んだり、表示された新しいものが好きになったら、簡単に救済することができます。メッセージングのオーバーヘッドは通常、要求をパッキングして処理します。さまざまなレベルのトラフィックと時間の経過とともに異なる対称性に対して異なるシステムが設計されています。

基本機能を抽象化すると、必要に応じて機構を入れ替えたり、より正確に評価したりすることができます。

受信者のストレスが変化すると、アプリケーションまたはメッセージルートのさまざまな部分でメッセージを変換することもできます。たとえば、上位レベルでは1000：1/s vs 10：1/sなどです。

グッドラック