71

JMS が適切な解決策である問題の (単純な) 例と、これらの場合に JMS が適切な解決策である理由も探しています。以前は、B がメッセージをすぐに処理できない場合に、A から B にメッセージを渡す手段として単純にデータベースを使用していました。

このようなシステムの架空の例として、新しく登録されたすべてのユーザーに、登録後 24 時間以内にウェルカム メールが送信されるようにする必要があります。議論のために、DB は各ユーザーが登録した時刻を記録するのではなく、各新規ユーザーへの参照 (外部キー) が pending_email テーブルに格納されていると仮定します。電子メール送信者ジョブは 24 時間ごとに実行され、このテーブル内のすべてのユーザーに電子メールを送信し、すべての pending_email レコードを削除します。

これは、JMS を使用する必要がある問題のように思えますが、私が説明したアプローチに対して JMS がどのような利点をもたらすかは明確ではありません。DB アプローチの利点の 1 つは、メッセージが永続的であることです。JMS メッセージ キューも永続化できることは理解していますが、その場合、JMS と私が説明した「メッセージ キューとしてのデータベース」アプローチとの間にほとんど違いはないように思われます。

私は何が欠けていますか？- ドン

4

11 に答える 11

70

JMS とメッセージングは​​、実際には 2 つのまったく異なるものです。

  • パブリッシュとサブスクライブ (関心のある多くの消費者にメッセージを送信 - メーリング リストに電子メールを送信するのと少し似ています。送信者は、誰がサブスクライブしているかを知る必要はありません。
  • 高性能で信頼性の高い負荷分散 (メッセージ キュー)

キューとトピックを比較する方法の詳細を参照してください

あなたが話しているケースは2番目のケースです.はい、データベーステーブルを使用してメッセージキューをシミュレートできます.

主な違いは、JMS メッセージ キューが、巨大なスループット用に設計された高性能で高度な同時実行ロード バランサであることです。通常、1 秒あたり数万のメッセージを、多くのプロセスとスレッドの多くの同時コンシューマーに送信できます。この理由は、メッセージ キューは基本的に非同期性が高いためです。優れた JMS プロバイダーは、各コンシューマーに事前にメッセージをストリーミングし、コンシューマーが利用可能になるとすぐに RAM で処理できる数千のメッセージを利用できるようにします。これにより、大量のスループットと非常に低いレイテンシが実現します。

たとえば、データベース テーブルを使用して Web ロード バランサーを作成することを想像してみてください :)

データベース テーブルを使用する場合、通常、1 つのスレッドがテーブル全体をロックする傾向があるため、高パフォーマンスのロード バランサーを実装しようとすると、スループットが非常に低くなる傾向があります。

しかし、ほとんどのミドルウェアと同様に、すべては必要なものに依存します。1 秒あたり数メッセージしかないスループットの低いシステムを使用している場合は、データベース テーブルをキューとして自由に使用してください。ただし、低レイテンシと高スループットが必要な場合は、JMS キューを強くお勧めします。

于 2008-10-21T15:05:06.653 に答える
51

私の意見では、JMS やその他のメッセージベースのシステムは、次のような問題を解決することを目的としています。

  • 非同期通信: アプリケーションは、応答を待つ必要なく、イベントが発生したことを別のアプリケーションに通知する必要があります。
  • 信頼性。1 回限りのメッセージ配信を保証します。DB アプローチでは、特に複数のクライアントがメッセージを読んでいる場合は、「車輪を再発明」する必要があります。
  • 疎結合。すべてのシステムがデータベースを使用して通信できるわけではありません。そのため、JMS は、システムの境界を越えて通信できる分離されたシステムを持つ異種環境で使用するのに非常に適しています。
于 2008-10-21T14:23:38.033 に答える
7

JMS 実装は、新しいメッセージを検出するためにキューをポーリングする必要がないという意味で「プッシュ」ですが、新しいメッセージが到着するとすぐに呼び出されるコールバックを登録します。

于 2008-10-21T14:29:01.530 に答える
5

JMSの利点の1つは、データベースソリューションでも実行できる非同期処理を有効にすることです。ただし、データベースソリューションに対するJMSのその他の利点は次のとおりです。

a）メッセージの利用者は遠隔地にいる可能性があります。リモートアクセスのためにデータベースを公開することは危険です。これを回避するには、データベースからメッセージを読み取るための追加のサービスを提供します。これには、より多くの労力が必要です。

b）データベースの場合、メッセージコンシューマーはデータベースをポーリングしてメッセージを探す必要がありますが、JMSはメッセージが到着したときにコールバックを提供します（skが述べたように）

c）負荷分散-大量のメッセージが送信される場合、JMSにメッセージプロセッサのプールを簡単に設定できます。

d）一般に、JMSを介した実装は、データベースルートよりも簡単で、労力も少なくて済みます。

于 2008-10-22T08:28:36.563 に答える
5

元のコメントに対処します。最初に説明したのは (ポイントツーポイント) JMS の要点です。ただし、JMS の利点は次のとおりです。

  1. 自分でコードを書く必要はありません (そして、ロジックを台無しにして、思ったほど永続的でなくなる可能性があります)。また、サードパーティの実装は、単純なデータベース アプローチよりもスケーラブルな場合があります。

  2. jms はパブリッシュ/サブスクライブを処理します。これは、指定したポイントツーポイントの例よりも少し複雑です

  3. あなたは特定の実装に縛られておらず、Javaコードをいじることなく、将来ニーズが変わった場合にそれを交換することができます.

于 2008-10-21T14:56:15.237 に答える
1

ここにいくつかの例を含む素晴らしい記事があります: http://www.winslam.com/laramee/jms/index.html

于 2010-12-03T22:10:01.510 に答える
1

Guido は完全な定義を持っています。私の経験から、これらはすべて、適切にフィットするために重要です。

私が見た用途の 1 つは、倉庫での注文の配布です。大規模なオフィスに事務用品を供給するかなりの数の倉庫を持つ事務用品会社を想像してみてください。これらの注文は中央の場所に送られ、適切な倉庫に配送されるようにまとめられます。ほとんどの場合、倉庫は高速接続を持っていないか、必要としないため、注文はダイヤルアップ モデムを介して倉庫にプッシュ ダウンされます。これが非同期の出番です。電話回線もそれほど重要ではないため、注文の半分が入り、ここで信頼性が重要になります。

于 2008-10-21T14:30:25.647 に答える
1

主な利点は、共通のデータベースを共有したり、カスタム サービスを構築してデータを渡したりするのではなく、関連のないシステムを切り離すことです。

銀行は好例であり、日中のメッセージングを使用してライブデータの変更が発生したときに受け渡します。ソース システムが「壁を越えて」メッセージを送信するのは非常に簡単です。欠点は、これらのシステム間の契約方法がほとんどないことです。通常、入院は消費者側で実装されます。ほとんど疎結合です。

その他の利点は、多くのアプリケーション サーバーなどですぐに使用できる JMS のサポートと、それに関連するすべてのツール (耐久性、監視、レポート、スロットリング) にあります。

于 2008-10-21T14:46:40.263 に答える
0

JMS を JTA (Java Transaction API) および JPA (Java persistence API) と組み合わせると、非常に便利です。簡単なアノテーションを使用すると、複数のデータベース アクションとメッセージの送受信を同じトランザクションに含めることができます。そのため、いずれかが失敗すると、同じトランザクション メカニズムを使用してすべてがロールバックされます。

于 2010-07-25T08:14:26.210 に答える
0

「メッセージキューとしてのデータベース」ソリューションは、タスクにとって重い場合があります。JMS ソリューションは、メッセージの送信者が受信者について何も知る必要がないという点で、緊密に結合されていません。これは、「メッセージ キューとしてのデータベース」で追加の抽象化を行うことでも実現できるため、大きな利点ではありません...また、キューを「パブリッシュおよびサブスクライブ」の方法で使用することもできます。あなたは達成しようとしています。また、コンポーネントをさらに切り離す良い方法でもあります。すべての通信が 1 つのシステム内にある場合、および/またはアプリケーションですぐに利用できるログを持つことが非常に重要である場合、その方法は適切に思えます。別々のシステム間で通信している場合は、JMS が適しています。

于 2008-10-21T14:32:01.430 に答える