5

単一のサーバーと多数のクライアントを必要とするアプリケーションを開発しています。このタスクを実行するために、Java ソケット プログラミング API を利用しています。現時点では、アプリケーションの設計全体を再構築することを検討しています。これは、アプリケーションが最も効率的な方法で構造化されているとはまったく考えていないためです。最適なパスに向けたガイダンスをいただければ幸いです。

現在の実装

ポート 5000 に1 つServerSocketあり、ソケットを含むスレッドは継続的に実行され、あらゆる接続を受け入れます。次に、そのクライアントとの通信を処理する新しいサーバー スレッドを (使用可能なポートの同期テーブルに基づいて) 開始し、ServerSocket.accept()再びブロックします。

このメイン スレッドから生成されるスレッドには、ServerSocket複数の接続を一度に処理する手段として使用される も含まれます。

ここで、クライアント スレッドは単純にポート 5000 に接続し、次の使用可能なポートを応答として受信し、( を呼び出してSocket.close()) ポート 5000 から切断し、サーバーが使用可能であると言ったポートに再接続します。

私の質問

これは、単一のサーバーで複数のクライアントを処理するための最も最適な方法ですか? ServerSocketまたは、利用可能なすべてのポートで単に 's を開き、常にリッスンする必要がありますか? おそらく私がまだ考えていない何か？

補遺

MMORPG やチャット アプリケーションなどの非常に大規模なクライアント サーバー アプリケーションの観点から、実装の実現可能性を感じようとしています。たとえば、「これは機能するかもしれませんが、このアプリケーションが大規模なユーザーベースを持っている場合、それは良い解決策でしょうか?」と自問してみます。そうは言っても、たとえば何百万人ものユーザーがいる大規模な環境でソリューションがどのように機能するかを確認できれば、ソリューションの最適な性質を理解しやすくなります。

4

4 に答える 4

6

メインの ServerSocket が接続を受け入れるたびに新しい ServerSocket を使用する必要がある理由がわかりません。( Java チュートリアルaccept()で説明されているように)によって返されたソケットを単純に使用しないのはなぜですか?

また、クライアントごとに新しいスレッドを開始する代わりに、スレッド プールを使用する必要があります。これにより、常に新しいスレッドが作成されることを回避でき、スレッドを開始しすぎてサーバーが機能しなくなることを回避できます。

ただし、このアーキテクチャは、膨大な数のユーザーを処理するのに最適なものではありません。そのようなスケーラビリティが本当に必要な場合は、非同期 IO を使用する方がおそらくより良い解決策になるでしょうが、私はそれについてあまり経験がありません。

于 2012-11-04T16:02:12.067 に答える
3

サーバー アーキテクチャを考えるとき、最初の質問は、単一の接続に必要なメモリ量と処理能力を見積もることです。2 つ目は同時接続数です。乗算後、単一のマシンで十分か、クラスターが必要かを判断できます。

次に、接続用のスレッド (約 128..512 キロバイト) を確保できるかどうかを判断します。可能であれば、接続ごとに従来の 1 スレッドで問題ありません。それができない場合は、NIO または NIO2 に基づく非同期アーキテクチャが適しています。

基本的な決定が完了したら、適切なライブラリとフレームワークを選択できます。すべてをゼロから行う方が面白いのですが、非常に時間がかかるため、結果が得られた時点では誰も興味を持たない可能性があります。

于 2012-11-04T17:18:32.010 に答える
1

ポート5000の単一サーバーがボトルネックであるため、次の提案に同意します。

または、使用可能なすべてのポートでServerSocketを開いて、常にリッスンする必要がありますか？

私はserversocketのプールを好みます。

于 2012-11-04T15:59:34.243 に答える
1

JMS (私の場合はその ActiveMq)を使用して、目標を達成します。ロード バランシングとフェイルオーバーを簡単に行うことができます

于 2012-11-04T16:07:17.000 に答える