リアルタイムゲームに最適なサーバーアーキテクチャは何ですか？

私は何千人ものプレイヤーをリアルタイムで保持できるリアルタイムゲームを開発しています（FPSなど。最大1秒のラグ）。これに最適なインフラストラクチャは何でしょうか？

私のアイデアは、2つのサーバークラスターを使用することでした。1つはサーバーエンド（すべてのコンピューティング側）用で、もう1つはデータベースエンド用で、各クラスターに対してロードバランサーが「責任を負います」。1つのメインサーバーがユーザーからの要求を受信し、ユーザーがこれを実行できる関連サーバーのIPアドレスを返信します。

データベースクラスターは、データベース間の整合性のためにデータベースレプリケーションを使用します。

地理的なロードバランサーも必要です。最適なレスポンスを得るために、地域のロードバランサーを各ユーザーに割り当てます。

ゲームには.NET + MSSQLを使用しています。

ありがとう！

たとえば、要件についてより多くの知識がなければ、最良のアーキテクチャはありません。キャラクター間の相互作用の種類、永続化されるデータの量など。

1秒のレイテンシに対処できれば、おそらく1台のサーバーで1000人のプレイヤーを問題なくホストできます。ただし、通常ははるかに低いレイテンシを必要とするため、FPSのアイデアと実際には競合します。100ms未満。しかし、高レイテンシを処理できるシステムでは、メッセージパッシングを介してすべてを実行できるため、一貫性が非常に簡単になります。ロジックの提供は非常に単純です。つまり、複雑なロジックは、オブジェクトをロックされたオブジェクトシステムではなくメッセージベースのシステムにするとさらに悪化しますが、すべてアプリケーションのニーズに依存します。

同様に、多くのデータを永続化しない場合、データベースマシンはまったく必要ありませんが、それを知らなければ、言うことは困難です。少量のデータを保持していて、おそらくトーナメントや何かの終わりにそれを実行しているだけの場合は、個別のデータベースは必要ありません。それらのクラスターは必要ありません。一方、多くの時間を費やさずに多くを読んでいる場合は、複製されたデータベースが役立ちますが、リレーショナルデータベースがそもそも問題に最適ではない可能性があることも示しています。多くの場合、インメモリキャッシュの方が優れたソリューションです。同様に、キャラクター間にトランザクションスタイルの相互作用がない場合、一貫性はそれほど重要ではなくなります。（そのようなトランザクションが少ししかない場合は、それらを特別なケースにすることができます。）

実際、RDBMSの採用は、大規模なシステムで行われているという理由だけで注意してください。私は個人的にオンラインゲームでそれらを使用することを承認しますが、優先データベースを取得し、それをキャッシュとレプリケーションで微調整して自分に合うようにするのではなく、要件を検討し、そこから永続化戦略を理解するのが最善です。アプリ。必要なのはオフラインレポート機能だけである場合があります。その場合は、バックグラウンドプロセスでゲームの永続化メカニズムから別の場所のリモートRDBMSにログを記録するのがおそらく最善です。

免責事項：私のゲームプログラミングエクスペリエンスはクライアント側のシングルプレーヤーゲームに基づいていますが、私はWebアプリケーション（特にMicrosoftスタック）にバックグラウンドを持っているので、この答えをもとにしてきたので、適用しますが、実際のゲームサーバーを実際にテストしないと、それがどのように適用されるかを言うのは困難ですが、ここにいきます。これを知ってください：私はゲームサーバーを展開していません、webappsだけです。

2つの（サーバー）層アプローチをお勧めします。データベース層と「アプリケーション」層。3番目の（プレゼンテーション）層はゲームクライアントです。

リレーショナルデータベースは、データのクエリに優れ、データの書き込みに優れています。重要なのは、データベースの書き込みを、クラスターが処理できる管理可能なサイズのチャンクにシリアル化することです。SQL Serverのより高度なエディション（データセンター/エンタープライズ）は、クラスタリングとレプリケーションをサポートしています。まず、小さなクラスターを構築し、それに対していくつかのクエリを実行して、それがどのように機能するかを確認します。

アプリケーション層では、「ゾーニング」などを行っている場合は、クラスターを設定せずに、ゾーンごとにサーバーを設定するだけで済みます。ゾーンが大きくなった場合は、ゾーンごとにクラスターをセットアップできます。

アプリケーション層->データベース層からデータを送信するためのシリアル化プロセスを構築する必要があります。重要なのは、複数のレベルのシリアル化を行うことです。何かのように、この：

• レベル1：X秒ごとにDBに保存します。重要なデータが含まれます。
  • プレイヤーの健康
  • プレイヤーアイテム/ピックアップ
• レベル2：2X秒ごとにDBに保存、中程度のデータを含む：
  • プレーヤーの場所
  • NPCの場所
• レベル3：その他すべて、可能な限りまれに

これにより、書き込みの一貫性と予測可能性が維持されます。ゲームの性質によっては、データベースへの書き込みがまれである可能性もあります。重要なのは、アプリケーションサーバーがクラッシュした場合、データベースの状態からオンラインに戻る必要があるため、90分ごとにプレーヤーのインベントリをシリアル化すると、プレーヤーが混乱する可能性があるということです。

データを読み取るには、アプリケーション層のメモリにできるだけ多くロードし、すべてのコードがこのメモリプールを使用するようにします。バックグラウンドで、メモリプールをデータベースと同期できます。Joeが指摘するように、「リアルタイム」のトランザクションが必要になる場合があります。ほとんどの書き込みをシリアル化することで、データベースサーバー/クラスターに十分なハードウェアがあると想定して、必要に応じてリアルタイムトランザクションを実行するためにデータベースに十分なIOが必要です。