JBoss Messaging (JMS) を多用するプロジェクトに取り組んでいます。私は、他の開発者向けに Messaging の使いやすいラッパーを構築する任務を負っており、JMS のメッセージ セレクターを使用してフィルタリング技術を提供し、不要なメッセージの送信を最小限に抑えることを考えています。パフォーマンスに関して誰かが経験を持っているかどうか知りたいですか? 私が恐れているのは、JMS プロバイダーがメッセージ セレクターで行き詰まり、目的全体を事実上無効にしてしまうのではないかということです。ただし、メッセージの種類ごとにトピック/キューの長いリストを作成するよりもはるかに優れています。
最終的には、間違いなくこの 2 つの組み合わせを使用することになりますが、どちらに傾倒しても、パフォーマンスへの影響が懸念されます。
私の2セント：
私は ActiveMQ に関してまったく同じ質問を自問しました。
私は抽象化レイヤーを開発し、開発者が質問せずにコーディングできるようにし、実装を切り替えてテストを行いました。
JBoss MQ 実装に関する私の経験から、クライアントはメッセージ セレクターを使用してメッセージをフィルタリングしていました。明らかに、これはトピック内のすべてのメッセージが、たとえ無視されたとしても、すべての受信者に送信されることを意味します。一方、サーバー上のさまざまなキューとトピックは、サーバーのパフォーマンスに影響します。
セレクターの急増はクライアントとネットワークの負荷に影響し、トピックとキューの急増はサーバーの負荷に影響すると思います。明らかに、ネットワークの負荷、メッセージ コンシューマの負荷、およびメッセージ プロデューサの負荷はすべて異なる方法でスケーリングされます。
単純なケースを超えて、ラッパーはトリッキーになります。エラー処理と JMS API を、特定のニーズを満たすように概念的に構成された単純なメッセージ パッシング API にラップすることをお勧めします。次に、カバーの下で、最小限の手間で上記のさまざまなデザインのいずれかに変更できます.
うーん、疑問があります。JMS は非常に使いやすいです。これが試されたのを見たことがありますが、使いやすいソリューションは使いにくく、バグが多かったです。