データベースを使用する分散C ++ゲームサーバー

私のC ++ターンベースのゲームサーバー（データベースを使用）は、現在の平均的なクライアント（プレーヤー）の量に対抗できないため、すべてのクライアントが依然として存在する複数（1以上）のコンピューターとデータベースに拡張したいと考えています。単一のゲームの世界（サーバーは互いに通信し、複数のデータベースを使用する必要があります）。

最良の方法でそれを行う方法を説明するいくつかのチュートリアル/本/共通の標準はありますか？

「単一のゲーム世界にとどまる」というMMO用語は、シングルシャードです。 EVE onlineは、すべてのプレーヤーを1つのシャードに詰め込むことを試みる唯一の主要なMMOです。

幸運なことに、彼らはその方法について非常に有益な記事を公​​開しました。

_{（ソース：gamasutra.com）}

悪い知らせ。EVE onlineの手法を一般的に適用することはできません。それらのソリューションは、特定のジャンルと実装に完全に適合しています。
注：すべてのEVE onlineの超高級シングルシャードネットワークでは、1つのデータベースを使用します。彼らは、分散データベース用のスケーラブルで一貫性のある、適度にリアルタイムのソリューションを設計することができませんでした。

どちらの方法で彼らがそれをしたかを読むことはあなたがあなた自身の解決策を設計するのを助けるべきです。ただし、非常に難しい問題を解決しようとしていることに注意してください。

ゲームサーバーを配布する代わりに、まず他の方法を検討することをお勧めします。

• ゲームサーバーのプロファイルを作成します。
  • それが問題である場合、サーバーのコードを最適化してCPUの負担を抑えます。
  • クライアントとサーバー間の通信プロトコルを最適化して、ネットワークのチャタリングを削減します。
• ゲーマーサーバーをデータベース通信に最適化します。
  • クエリオプティマイザーを実行し、必要に応じて変更を加えます。
  • DBの相互作用を最小限に抑える
• DBを別のマシンに移動します。
  これはしばしばトンを助けます。可能であればDBを同じローカルネットワーク上に置いてください。ただし、サーバーハードウェア上で実行されているのがゲームサーバーだけの場合は、ゲームサーバーがより元気になるのに役立ちます。

最初の移動は、ゲームサーバーからのデータベースへの直接アクセスを分離し、使用状況に応じたミドルウェアを使用してサーバーのデータを準備することです（XML、JSONなど）。これらは、任意の数のデータベースを処理でき、さらに重要なことに、アプリケーション固有のキャッシュオプションを提供できます。できる限りキャッシュを作成し、必要な場合にのみデータベースを取得します。シナリオで可能な限り最高のパフォーマンスを達成するために、多くの小さなクエリの代わりに大きなフェッチを行います。

選択したデータベースでは、クラスターを操作して、利用可能なデータベースリソースを簡単に拡張し、結果をより速く提供することもできますが、これは、多くの経験と専任のデータベース管理者がセットアップと保守を行う必要があるテーマです。インディーズ予算にも当てはまりません。

ゲームサーバーについて：一般的な戦略は、各サーバーがゲームの世界の一部を管理する複数のサーバーを使用することです。各ユーザーは通常、周囲で何が起こっているかを知るだけでよいため、世界を地域ごとに分割することは理にかなっています。残念ながら、クローズドゾーンとプレイヤーがテレポートすることで構成される世界ではなく、境界線のないオープンワールドがある場合、これはさらに複雑になります。オープンワールドがある場合は、シームレスな方法でゾーン間でプレーヤーを転送する方法と、サーバー間の境界付近の領域を同期する方法が必要です。それはトリッキーな問題です。

データベースについて： SQLデータベースは通常、スケーリングが不十分です。それらは配布されるようには設計されていません。しかし、現在、MongoDBやCassandraのようなNoSQLデータベースは、複数のサーバーに分散するように設計されているという、かなり新しい傾向があります。サーバーを追加するだけで、容量を簡単に追加できます。では、なぜすべての大規模なゲームがそれらに切り替わらないのですか？なぜなら：

1. SQLデータベースは40年以上存在していますが、NoSQLデータベースは数年しかありません。それらを最も効率的に使用する方法はまだノウハウがあまりなく、開発は急速に進んでいます。市場には競合する完全に互換性のない製品がたくさんありますが、どれが生き残り、数年で廃止されて廃止されるかはわかりません。大手企業のほとんどは、SQLの既知の欠点をNoSQLデータベースの未知のリスクよりも優先しています。
2. それらはSQLデータベースとは非常に異なって機能し、永続化戦略全体を再考する必要があります。これにより、ソフトウェアアーキテクチャ全体に劇的な変化が生じる可能性があります。

したがって、プロジェクトがすでに非常に進んでいる場合、別のデータベースソリューションへの切り替えは大きなリスクであり、時間とエネルギーの非常に大きな投資となる可能性があります。

いいえ。これは、まだ解決されていない非常に難しい領域です。

これは古いのですが……。

これに焦点を合わせるには、実際には2つの領域があります。

アプリケーションを複数のサーバーに分散する必要があります。データベースを複数のサーバーに分散する必要があります。

そして、両方に冗長性を持たせる必要があります。

これにはいくつかのオープンソースソリューションがあります。Farmvilleは、MemSQL / Couchbaseを使用した良い例です。