c# - .NET の MSMQ: 同期 vs 非同期?

Question

いつ、どのアプローチを使用しますか?

同期が専用の別のスレッドである場合、非同期メソッドを使用する理由はありますか?

Answer 1

非同期メソッドを使用して、呼び出し元のスレッドをブロックしないようにします。また、sync メソッドを使用する独自の専用スレッドを作成するのではなく、このアプローチを使用することをお勧めします。これは .NET の汎用的なアドバイスであり、独自の専用スレッドを作成するよりも、.NET に非同期処理を行わせる方が適切です。

編集: .NET の MSMQ の非同期モデルの一部である MSMQ と EndReceive に関して、興味深い質問が 1 つあります。

Answer 2

MSMQを使用する場合は、非同期アプローチを使用することをお勧めします。

MSMQの主な目的の1つは、分離されたシステム間でデータを送信するためのソリューションを提供することです。言い換えれば、理想的には、発行者と加入者の両方が、メッセージの内容を処理する方法を知っている限り、お互いについて何も知らないはずです。

これには、受信者が送信されたメッセージを処理するたびに送信者が心配する必要がないことが含まれます。すぐに処理することも、受信者のキューにすでに蓄積されている他の数千のメッセージの後で処理することもできます。

または、数時間または数日間オフラインになっている受信機について考えてみてください。トランザクションキューを使用する場合、受信者がオンラインに戻るとすぐにメッセージが配信されますが、同期的に長時間待機しますか？:-)

いつものように、それはあなたが何をしたいかに依存します。

たとえば、メッセージが特定の順序で処理されることを保証したい場合は、同期アプローチを使用すると役立つ場合があります。しかし、気にしない状況や、複雑すぎて保証できない状況がもっとあると思います。

私が何を意味するかを明確にするためのいくつかの例：

• ロードバランサー/ディスパッチャーを含むアーキテクチャを想像してみてください。そのバランサーが受信したメッセージを複数のサービスまたはスレッドに分散させる場合、順序やタイミングなどの側面に依存することはできません。私見、あなたはこれを同期的にしたくないでしょう。

• もう1つの一般的な方法は、単一のパブリッシャーに複数のサブスクライバーを配置することです。簡単な例として、最新のチャットメッセージを数百のチャットクライアントに送信したいチャットサーバーがあります。繰り返しますが、これを同期的に実行することは望ましくありません。

質問に戻ると、最初から非同期を使用するために何も提供していません。代わりに、その使用法を実装することで、柔軟性とスケーラビリティが得られます。

Answer 3

しばらくして...

非同期読み取りは読み取りスレッドを保持しません。コールバックを登録し、メッセージが完全に読み取られると、このメッセージで元の呼び出し先に戻ります。他の作業を行うためにスレッドが必要な場合、これは素晴らしいことです。

私が実際に見つけたのは、同期読み取りが非同期の 2 倍の速さであるということでした。関連するコールバックがなく、おそらくスレッド化のオーバーヘッドが少ないため、1 つのスレッドがキューから 2 倍の数のメッセージを読み取っていました。

やみくもに async-await パターンに従うのではなく、プラットフォームでこれを測定することをお勧めします (これは他のほとんどの場合に非常に適しています)。