1

私は現在、プロジェクト内のactiveMQに基づいて、キューまたはトピックの実装を調査しています。ビジネス ドメインに従ってビジネス ロジックを分離するために Maven モジュールを使用するセットアップは非常に簡単です。1 つの共通モジュールにより、共通ロジックを組み立てることができます。

簡略化された例:

  • 共通モジュール
  • 製品モジュール
  • クライアントモジュール

要件の 1 つは、特定の操作が (activeMQ を使用して) バックエンドに対して非同期であり、バックエンドが結果メッセージで応答することです。2 番目の要件は、より多くの機能が必要なモジュールのみを使用して新しいデプロイ可能なアーティファクトを作成することにより、アプリケーションを水平方向にスケーリングできる必要があることです。

もちろんjmsとactiveMQでSpring 4を使用しています。

私の質問に進みます。バックエンド接続に 1 つのキューまたはトピックのみを使用したいと考えています。これは、共通モジュールが jms 構成 (jms factory、jms-configuration) を処理し、さまざまなタイプのメッセージがその 1 つのキュー/トピックを介して送信されることを意味します。製品関連のメッセージが「products」モジュールで処理され、クライアント関連のメッセージが「clients」モジュールで処理されるようにするにはどうすればよいですか? モジュールが 2 回デプロイされた場合、「製品」モジュール ロジックの 1 つだけがメッセージを処理するようにするにはどうすればよいですか? どのようなアプローチをお勧めしますか、またはこれは 1 つのキュー/トピックの「ナッツ」ですか?

私自身、publ/subsc パターンのためにトピックを使用する方向で考えていました... または、製品またはクライアントのサブスクライバーがサブスクライブしてメッセージの処理を引き継ぐ可能性のあるオブザーバー パターンでパブリッシャーとして機能するキュー リスナーでしょうか?

ご協力いただきありがとうございます。

4

1 に答える 1

2

「製品」モジュールの 1 つだけで 1 つのメッセージを処理する場合、なぜトピックを使用するのでしょうか。トピックを使用すると、メッセージが 1 つになり、複数のサブスクライバーがそれぞれメッセージを受け取ります。Queue は、1 つのコンシューマーのみがメッセージを受け取ることを保証します (ポイント ツー ポイント)。Topic を使用すると、1 つのメッセージがすべてのサブスクライバーにディスパッチされます。

メッセージの「フィルタリング」に関しては、これはプロバイダー固有のものでなければなりません。ActiveMQ ドキュメントを見ると、これが表示されます。したがって、基本的に各コンシューマーは、ブローカーがセレクターに基づいてディスパッチするメッセージを取得する必要があります。詳細はわかりませんが、ここから調査を開始します。同じ考えで、Spring フォーラムのこのディスカッションを見てください。確かに、Spring Integration に関連していますが、メッセージ選択の考え方は同じです。一方、Spring Integration をプロジェクトに採用することを検討することもできます。これは一種の統合パターンの抽象化であり、すべてのメッセージ指向にうまく適合します。

そのフォーラム投稿からのいくつかの興味深いアイデア:

于 2014-08-22T06:11:30.393 に答える