高負荷Javaマルチプレイヤー用サーバー
マルチプレイヤーゲームを作成しています。 Androidデバイスをサーバーに接続するテクノロジーを選択しようとしています。クライアントはAndroidで動作し、ゲームはMMORPGです。サーバーをJavaで記述したいと思います。今はそのためのアイデアは3つしかありません。
1）単純なJavaとソケットを使用してマルチスレッド環境を作成します。このようにすると、ゲームクライアントとサーバーですが、私は次の懸念事項があります：
1.1）ゲームはMMORPG=多数のオブジェクトであり、同時に5000人が同時にプレイしている場合など、このようなソリューションがどのようにスケーリングされるのかわかりません。スレッド数はJavaマシン上で実行できますか？どのように計算できますか？ソケットごとに1つのスレッドが読み取り、ソケットに1つのスレッドが書き込んでいる場合（1つのプレーヤーに対して2つのスレッド）。
1.2）プレーヤーの数が増えると、自分で作成したjarアーカイブをスケーリングして複数のサーバーに分散させるにはどうすればよいですか？多分それを行うためのいくつかの特別なトリックがありますか？
1.3）プログラミングのオーバーヘッドが多い-ソケットAPIはかなり低レベルです。
2）HTTPリクエストを処理するためのサーブレットインターフェイスを作成します。
2.1）各プレーヤーが自分のセッションを持っている限り、セッション（および認証）を簡単に制御できます。
2.2）Java EE EJBまたは何にでも接続できます-システムレベルのプログラミングの多くの複雑さが取り除かれるので、ビジネスロジックの作成に集中できます。
2.3）HTTPを使用するすべてのタイプのクライアントに対応できます-モバイルデバイス+ブラウザ。
2.4）高速-1つのサーブレットコンテナでも1秒あたり数千のリクエストを処理できるため、非常に高速です。
2.4）しかし、このアプローチでは全二重通信を提供できません。更新を確認するには、1秒ごとにリクエストを送信する必要があります。 1秒の遅延はターンベースなので、ゲームに大きな影響はありませんが、それでも大量のトラフィックが発生します。多くのプレーヤーがプレイしている場合、それは可能ですか？いくつかのCOMETテクノロジーについて聞いたことがありますが、サーバーが多数のメッセージを連続してプッシュする必要がある場合、毎回リクエストを送信する必要があるようです+このテクノロジーはまだ十分に確立されていません。
3）ソケットを作成し、JMSを介してJava EEサーバーに接続します。
3.1）クライアントとサーバー間の全二重通信を可能にするため、クールです。Java EEのすべてのクールな機能を提供します。後でサーブレットインターフェースを介してブラウザに拡張できます。
3.2）ある種のオーバーエンジニアリングのようです。それは本当に人々がそれをする方法ですか？つまりそれは正しい方法ですか？正気な開発者はそれをそのようにしますか？
どうぞ私を助けてください。そのような仕事をした経験はあまりありません。そして、ベストプラクティスに固執したいと思います。
既成の内容を書き換える理由
RedDwarf Server （以前の Project DarkStar ）を使用しないのはなぜですか？
RedDwarf Serverは、大規模マルチプレイヤーオンラインゲームのサーバー側を開発するためのオープンソースミドルウェアソリューションです。これは、Sun Microsystemsがサポートおよび管理するオープンソースプロジェクトであるProject Darkstarの公式コミュニティフォークです。 -from RedDwarfのWikipediaの記事
RedDwarfのドメインは本日（2013-06-12）ダウンしているようですが、まだ wiki があり、 GitHubリポジトリ に移行しています。
RedDwardはその哲学と目標を次のように提示します。
- サーバーデベロッパーのゲームコードを、ゲーム開発者に透過的な方法で、信頼性が高く、スケーラブルで、永続的で、フォールトトレラントにしてください。
- シンプルなシングルスレッドのイベント駆動型プログラミングモデルを開発者に提示します。異なるイベントを処理するコード間の相互作用により、開発者は自分のコードが失敗することはありません。 （- RedDwarfチュートリアル ）から
これはサーバーコードがシングルスレッドであることを意味するのではなく、ゲーム開発者の観点から抽象化されていることを意味します。 RedDwarfチュートリアル は、RedDwarfが実行できることに関する多くの情報を提供し、その設計上の決定の多くを明確にします。
ただし、前回確認したとき（2011年頃）に、マルチノード機能が完全に実装されていなかったことが1つの懸念事項でした。
ゼロから
学習経験を重視する場合でも、これらのことのほとんどを最初からやり直すことを妨げるものではありません。ただし、これは主要な作業であり、かなり時間がかかります。また、質問で指摘したように、これらの問題のいくつかは処理する技術スタックではかなり低レベルであり、コードの複雑さが大幅に増加します維持する必要があります。
しかし、とにかく、あなたが自家製の実装に行くなら、あなたにとって3つのオプションに関して、あなたにとって最初のものが最も良いように思えます。オプション2（HTTPサーブレットを使用）は一部のゲームにのみ適応しているようですが、ミドルウェアに委任しながら自分で何かを実装するのは比較的まともな代替手段であり、負荷を処理するために多くのWebサーバーを追加することでメリットが得られると思います（キャッシュモジュールなど...）。オプション3（JMS + JEEを使用）は確かに過度に設計されているように見えますが、何を考えているのかを知らなければ、確実に知ることは困難です。
そして、あなたがここで学ぼうとしているなら、明らかにオプション1は多くの範囲をカバーします。しかし、それはかなり困難な戦いになるでしょう。
1.1）ユーザーごとに1つのスレッドを考えることはできません。マシンの構成にもよりますが、何千ものスレッドをロードすることはできますが、スレッドコンテキストスイッチではスケーリングせず、多くの時間を失うことになります。ミリ秒未満の実行で着信メッセージを実行する着信および発信スレッドプールエグゼキュータがほとんどないNIO Nettyのようなフレームワークを考えるとよいでしょう。
1.2）ゲームサーバーの前にロードバランサーコンポーネントを配置することで、単純にスケーリングできます。
1.3）NIOは、1つのボックスで数千から数百万の接続を処理できます。心配しないでください。
2.1）プレーヤーセッションを管理し、2.2）EJBアーキテクチャから離れてください。それはあなたのゴールであるあなたのゲームにパワーを割り当てる代わりにあなたのすべてのボックスパワーを消費します。
2.3）HTTPはすべてのクライアントにサービスを提供できますが、リアルタイムゲームを実行する場合は、バイナリソケットを使用し、ソケット接続を確立できない場合は、負荷分散、ログイン、統計、およびフォールバックのためにのみHTTPを維持することをお勧めします。
2.4）ソケットベースのサーバーは、毎秒数十万の着信メッセージを処理できます。これは低遅延システムの特性です
そのようなシステムの構築に飛び込むことは非常に興味深いですが。あなたの目標は何ですか？そのようなシステムを構築するか、ゲームを成功させることを学びますか？
多くのJavaマルチプレイヤーゲームサーバーテクノロジーフレームワークはすでに存在しています。SmartFoxサーバー、ElectroTank ...
独自のJava高負荷 NuggetaマルチプレイヤークロスプラットフォームJavaゲームサーバー があり、上記で説明したすべてのポイントに対処します。無料で試してみたい。
ゲームサーバーを作成することが目標の場合、長い時間がかかる可能性がありますが、非常にエキサイティングです。ゲームを成功させることが目標の場合。 JavaゲームサーバーSDKが既に存在する間でピックアップします。