私は、メッセージ駆動型 Bean (MDB) の複数のインスタンスがリッスンするメッセージ キューに複数の作業単位を配置することによって同時実行性を実現するデータ処理アプリケーションに取り組んでいます。この方法で並行性を実現する以外に、メッセージング インフラストラクチャと MDB を使用する特定の理由はありません。
これにより、複数のスレッドを使用して同じことが達成できなかった理由を考えるようになりました。
私の質問は、どのような状況で非同期メッセージング (JMS など) を同時実行を実現する手段としてマルチスレッドの代わりに使用できるかということです。あるアプローチを別のアプローチよりも使用する利点/欠点は何ですか。
マルチスレッドの代替として使用することはできません。マルチスレッドを実装する方法です。ここには、3 つの基本的な種類のソリューションがあります。
データの受信はここでキッカーです。何らかの形のマルチスレッド/マルチプロセッシングなしではそれを行う方法が実際にはないためです。そうしないと、一度に 1 つのリクエストしか処理できなくなります。マルチスレッドを使用せずにデータを送信する方がはるかに実行可能ですが、これらのメッセージを処理する責任を外部システムに押し付けているだけです。したがって、マルチスレッドに代わるものではありません。
メッセージ駆動型 Bean の場合、コンテナがスレッドを作成および管理しているため、マルチスレッドの代わりにはなりません。単に他の誰かの実装を使用しているだけです。
言及されていないと思われる追加のボーナスが 2 つあります。トランザクションと耐久性です。
これは必須ではなく、ほとんどの場合デフォルトの構成ではありませんが、JMS プロバイダーは、メッセージを保持し、コードをほとんどまたはまったく変更せずに XA トランザクションに参加するように構成できます。
EJB コンテナーでは、実際には代替手段はありません。EJB コンテナー内に独自のスレッドを作成することは許可されていないためです。JMS がそのすべての作業を実行しますが、キュー プロセッサを介して実行するというコストがかかります。コンテナとより密接な関係を持つ (したがって、スレッドを持つことができる) Java コネクタを作成することもできますが、それには多くの作業が必要です。
JMS キューの使用によるオーバーヘッドがパフォーマンスに影響を与えていない場合は、これが最も簡単な解決策です。
メッセージングを使用して追加のネットワーク層を追加するため、パフォーマンスに関するマルチスレッドは、どのメッセージングよりも高速である必要があります。
アプリケーションごとのメッセージングは、共通のオブジェクトがないため、ロックやデータ共有の問題を回避するのに役立ちます。
アプリケーションを変更する代わりにメッセージ サービスを構成することで、複数のサーバー上でより多くのノードを構成できるため、スケーリングの観点からは、メッセージングの方がはるかに優れています。
メッセージングは、データ競合のリスクを軽減するため、マルチスレッド アプリケーションのエラー数を大幅に減らすことができます。また、アプリの残りの部分を変更することなく、新しいスレッドを簡単に追加できます。
ここでは JMS が少し誤用されていると思いますが。java.util.concurrent のスレッドセーフなキューとjetlangなどのライブラリを使用すると、パフォーマンスが向上する場合があります。