マルチスレッドメッセージングサーバーの設計パターン
Javaでのマルチスレッドとデザインパターンの理解と応用を向上させるための個人的な演習として、インスタントメッセージングサーバーを設計しています。まだ設計中です。まだコードはありません。
私の目標は、マルチCPUボックスを効果的に使用できるサーバーを用意することです。サーバーを複数のボックスに分散できるようにしたいのですが、歩く前にサーバーが稼働しているかどうか疑問に思います。
私の最初の考えは次のとおりです。
ClientConnectionManagerには、クライアントServerSocket接続を常に受け入れるSocketオブジェクトがあります。ClientConnectionManagerには、クライアントソケット接続が受け入れられたときに新しいClientProxyオブジェクトを生成するスレッドプールがあり、クライアントSocketオブジェクトを渡します。ClientProxyオブジェクトはクライアントアプリを表し、Socketストリームを介したメッセージの送受信を処理します。
1つのServerSocketのみがポートにバインドできることは正しいですか？私は、ソケット接続を受け入れるオブジェクトのプールを持つ方法がないと思いますか？
ClientProxyオブジェクト間でメッセージを渡すための2つのアイデアがあります。 「バディ」であるClientProxyオブジェクト間、または中央の「Exchange」オブジェクトを介して直接、あるいはオブジェクトのプール。
2つのアプローチの長所と短所は何ですか？ Exchangeは分散アプリに適していますか？
オブザーバーとメディエーターのパターンはそれぞれ適切でしょうか？
1つのServerSocketのみがポートにバインドできることは正しいですか？私は、ソケット接続を受け入れるオブジェクトのプールを持つ方法がないと思いますか？
正しい。特定のネットワークインターフェースの特定のポートに同時にバインドできるのは1つだけです。接続が受信されるたびに、クライアント用の新しいソケットが遅延/内部ルーティングポートで自動的に作成されます。これにより、単一のリスナーが、前のリスナーが切断するのを待たずに、任意の数のクライアントハンドラーを生成できます。
ClientProxyオブジェクト間でメッセージを渡すための2つのアイデアがあります。 「バディ」であるClientProxyオブジェクト間、または中央の「Exchange」オブジェクトを介して直接、あるいはオブジェクトのプール。
バディがオンラインになるたびに、クライアントにバディのメッセージキューへのプロキシを受信させることができます。その後、メッセージを相互に直接キューイングできるため、集中交換の必要がなくなります。サーバーは、すべてのオンラインクライアントへの参照を保持し、キューを介して友人の接続/切断を関係者に通知します。
これをスケーリングして単一のボックスを埋めるには、ネットワークインターフェイスを追加する（または1つのインターフェイスでポート範囲を使用する）ことになります。複数のボックス間でこれをスケーリングするには、サーバーの同期化/キュープロキシを行き来する必要がありません。