JBoss Seam - アプリケーション内の大量のメッセージング

Question

私は現在、次のチャットの例えに一致する設定を持つアプリケーションをいじっています。

• チャットはメモリに保持され、チャットメッセージのリストを含むオブジェクトです
• いくつかのブラウザウィンドウでチャットがレンダリングされ、更新がA4Jで引き込まれます：プッシュ

プログラムによるセットアップは次のようになります。チャット オブジェクトのインスタンスとそのメッセージは、異なるセッションの PAGE スコープの Sea コンポーネント間で共有されます。ここで、セッションが新しいメッセージを投稿すると、つまりチャット オブジェクトを変更すると、新しい状態がすべてのクライアントの UI に中継されるように、すべての Seam コンポーネントに新しいメッセージが通知される必要があります。

これを実現するには次の 3 つの方法が考えられます。

1. Seam のイベントにはチャット ID がパラメータとして含まれており、各コンポーネントは ID をチェックしてメッセージを更新または無視します。
2. 各コンポーネントがチャットのみをフィルターでリッスンする JMS キューまたは 1 つの JMS トピック
3. 共有チャット オブジェクト内の純粋な Java リスナー メカニズム、つまり各 Seam コンポーネントはそれに登録され、通知は純粋で直接的な Java です。

議論のために、チャットの数が多く (数万人)、チャット ユーザーの数が少ない (たとえば 2 ～ 10 人) と仮定します。

それぞれのパフォーマンスはどのようにスケールされますか?Seam を使用してこれをうまく実行する方法について他に提案はありますか?

私が見たところ、(1) は統合されてクリーンになりますが、最終的には実際に必要とするコンポーネントは少数であるにもかかわらず、何万ものコンポーネントに通知することになります。したがって、おそらくスケールしないでしょう。

(2) は統合され、JMS プロバイダー (交換可能) のパフォーマンスのみに依存し、変更を加えることなくクラスター環境でも動作します。ここでの JMS のパフォーマンスについてはわかりません。1 秒あたり数百のメッセージと、さまざまなフィルターを使用する数千のリスナーは、多いか少ないでしょうか。

(3) は、必要なコンポーネントのみが通知され、通知は純粋で直接的な Java であるため、高速になります。ただし、セッション/コンポーネント/スレッド間で何かが行われるため、同時実行性/アクセスの問題が発生する可能性があります。

(1) と (3) の場合、クラスタリングをサポートするソリューションは、ある時点で必要に応じて手動で追加する必要があります。

Answer 1

2)をお勧めします。また、JMS を方程式から外すことをお勧めします。JMS を使用すると、メッセージング プロバイダーを切り替えることができますが、メッセージング システムのより高度な機能を使用できなくなります。Oracleデータベースを使用している場合 AQ 賢明な選択をするでしょう (ちなみに JMS をサポートしています)。それ以外の場合は、AMQP を使用することをお勧めします。 JBoss メッセージング または次のようなサードパーティのソリューション ラビットMQ.

明らかにメッセージングの問題があるため、メッセージング ソリューションの使用を選択する必要があります。