多段階の処理パイプラインを必要とする作業を分散しようとする場合、JMSとJavaSpaceの通信、同期、およびスループットのコスト制限は何ですか？
JavaUser
質問する
3555 次
3 に答える
2
ステージ間でメッセージを送信する SEDA が必要な場合は、MOM はロックを必要としないように設計されているため、高度な非同期性と並行性を実現できるため、JMS 実装は通常、はるかに高速でスケーラブルです。JMS を使用すると、起動時にコンシューマーをセットアップできます。通常、メッセージ ブローカーはできるだけ早くメッセージをアプリケーションにプッシュします。これにより、アプリケーションが処理できるようになるとすぐに、いつでも処理できる多くのメモリ内オブジェクトが利用可能になり、ネットワーク ラウンドが回避されます。トリップやロックなど。たとえば、プリフェッチが ActiveMQ でどのように機能するかを参照してください
メッセージングに JavaSpaces を使用すると、効率が低下する傾向があります。これは、一般に、エントリへの読み取り/書き込みなどでロックを使用する、よりデータベース中心のアプローチを使用して実装されるためです。よりおしゃべりになり、メッセージングの効率が低下します。
ただし、JavaSpaces アプローチの大きなメリットは、共有状態が必要な場合です。JavaSpace を一種のデータベースとして使用できます。ただし、本当にデータベースが必要な場合は、JMS でリレーショナル データベースを使用できます。しかし、JavaSpace 関係者は、共有状態とメッセージングに単一のシステムを使用することを好みます。
FWIW 多くの場合、ミドルウェアには特効薬はありません。メモリー内の SEDA だけで十分な場合もあれば、JMS、リレーショナル データベース、ディレクトリ内のファイルの場合もあります。要件、スケーラビリティ、スループット、信頼性などに完全に依存します。ミドルウェア API をコードから隠すことをお勧めする傾向があります。これにより、Apache Camel を使用するなど、単純な 1 行の構成変更を介して、必要なミドルウェアに簡単に切り替えることができます。
于 2008-09-29T09:52:02.543 に答える
1
JMS は製品ではなく API です。「通信、同期、およびスループットのコスト」を持つことはできません。JMS の特定の実装 (Weblogic、JBoss、Tibco など) は可能です。
JMS には同期関数はありません。キューはキューです。あるメッセージ (あるキュー内) を別のメッセージ (別のキュー内) で待機させることはできません。
于 2008-09-24T17:27:08.210 に答える