2

私は現在、複数のサーバー(マシン)を使用してチャットの開発を開始する段階にあります(実際には、古い単一サーバーバージョンを移植しています)。

Java NIO ライブラリを使用したい。

私がこれを行っている理由は、膨大な数のクライアント (約 10k) が接続されているときに現在の実装が非常に遅く動作しているためです。また、現在の実装は IO ソケット ライブラリに基づいています。また、1 年で約 40 ~ 50,000 のライブ クライアントがあると見積もっています。

だから..いくつか質問があります:

  1. 古いソケット実装よりもはるかに優れていると聞いたので、NIO が処理できるクライアント数はいくつだと思いますか?
  2. 何かアイデアはありますか、またはマルチサーバーチャットを使用する既に実装されているアーキテクチャを教えてください。
  3. マルチサーバー アーキテクチャを使用する際に直面する可能性のある主な問題は何ですか?

前もって感謝します

4

2 に答える 2

3

NIO ライブラリの観点からは制限はないと思います。結局のところ、パフォーマンスはサーバーとネットワークの構成によって異なります。


NIO フレームワークのApache MINA Projectをご覧になることをお勧め します。

Apache MINA は、ユーザーが高性能でスケーラビリティの高いネットワーク アプリケーションを簡単に開発できるようにするネットワーク アプリケーション フレームワークです。Java NIO を介して、TCP/IP や UDP/IP などのさまざまなトランスポートを介して、抽象的な · イベント駆動型 · 非同期 API を提供します。

Apache MINA はよく次のように呼ばれます:
. NIOフレームワーク・ライブラリ、
. クライアント · サーバー フレームワーク · ライブラリ、または
. ネットワーク · ソケット ライブラリ。

于 2011-04-26T14:55:48.240 に答える
2

パフォーマンス テストを行わずに見積もりを出すのは困難です。サポートできるクライアントの数は、メモリ、プロセッサの速度/負荷、帯域幅/ボリューム、遅延要件、ストレージ要件などによって異なります。

サーバー間でデータを共有するために使用できるアプローチがいくつかあります。最もスケーラブルなアプローチであるため、それらの間でブロードキャスト/マルチキャスト UDP を使用します。

直面する可能性が高い最大の問題は、サーバーの停止に対処し、負荷分散を適切に処理することです。

編集 サーバー間でNIOに縛られていない場合は、pub/subモードのJMSが良い解決策かもしれません。

于 2011-04-26T15:11:28.360 に答える