そこで、プロデューサー/コンシューマー パターンに適したアプリケーションを作成することを計画しています。私は独自のプロデューサー/コンシューマー フレームワークを構築することを考えていましたが、仕事で広く使用するメッセージ キューについて考えました。私が書いているアプリケーションの複数のモジュールが、その特定のホストの一種のクライアント/コントローラーとして単一のサーバー上で実行する必要があることを考えると、メッセージング キューが正しいアプローチであると 100% 確信しているわけではありません。
非分散アプリケーションでメッセージング キューを使用する場合の長所と短所は何ですか? 誰かが以前にこのように使用したことがありますか?
ありがとう、さらに情報が必要な場合はお知らせください。
「メッセージキュー」とは、外部メッセージサーバーを意味しますか? 以下の私の答えは、それがあなたが何をしていたかを前提としています。メソッド呼び出しの代わりにメモリ内メッセージを介してモジュールが部分的または完全に通信するという、より一般的なアーキテクチャ アプローチについて質問している場合は、そうです。グアバの EvenBus のようなクラスは、このような設計をうまく促進します: https://code.google.com/p/guava-libraries/wiki/EventBusExplained
一方では、単純なキュー データ構造で十分な場合に、JMS メッセージ キューを使用することを思いとどまらせようとします。JMS は 1 対多 (トピック) および 1 対 1 の通信チャネルを持つプロセス間通信ツールであり、たまたま queues と名付けられていると感じることがあります。確かに、彼らのアクセス パターンはキューのそれに似ていますが、より重要な特徴は、ポイント ツー ポイントのメッセージング機能であるように私には思えます。そのため、ドライバー (java.lang.Queue) だけが必要な場合に、削岩機 (JMS) を使用することがあると思われる不幸な名前です。
一方で、どんな規則にも例外があります。サーバーの再起動時にスレッドセーフで永続的な java.lang.Queue 実装を推奨することはできません (人々が JMS を検討している場合によく必要とされる機能です)。いくつかあると思います。いくつか見つけて JMS と比較してください。ビジネス ニーズ、時間の制約、将来の設計/要件の可能性などを検討します。以前に自分で実装したことがありますが、非常に優れたものでした (ネットワーク経由でリモート JMS サーバーにメッセージを送信するよりも高速でした)--しかし、言えるのはあなただけです。これがあなたの状況に適している場合。
アプリのモジュールが、今のところ内部で java.lang.Queues を使用する独自のメッセージングのようなインターフェイスを介して通信するようにすることで、いつでも決定を延期できると思いますが、後で必要になった場合は JMS を使用します。ここでも注意が必要ですが、不必要な抽象化を早期に追加することは、負担になり、その価値がないことが判明する場合があります。