マシンのクラスタ全体で同じゲーム サーバーを利用できるようにしたいと考えています。最初の手順は問題ありません。リモート マシンでのレプリケーションによってデータベースを利用できるようにすることです。ただし、ゲームサーバー全体をレイヤーで設計することが重要です。ゲームサーバー自体を独自のアプリケーション、独自のパッケージにします。次に、データベースも分離して設計します。このデータベースは断片化し、複数のマシンに複製することができます。
このようにして、ゲーム サーバー用のデータ アクセス レイヤーを作成し、データ アクセス レイヤー API を使用して、サービスを中断することなく、実行時にリモート マシンまたはローカルでデータベースにアクセスできます。これらのデータベースに存在するデータが関連していないことが確実でない限り、各ゲーム サーバー インスタンスに独自の Mnesia スキーマを持たせるのは良くありません{local_content,true}
。
同じ Mnesia スキーマ (これはデータ ストレージ レイヤーにあります) を複数のマシンに複製する方が安全です。次に、テーブルを適切に設計します。ゲームデータを操作するモジュールで API を公開します。ここから、データ アクセス レイヤーの構築を開始します (
NOTE: Am talking of the 3-tier Logical Architecture, the Physical Architecture can take any form as long as it caters for Hardware and Network Failures.
)。データ アクセス レイヤーでは、フォールト トレラントなデータベース ノード アクセスが構築されます。ここに配置するメソッドは、アプリケーション (ビジネス ロジック) 層を抽象化して、接続の問題の処理、データベース ノードへのリモート プロシージャ コールの作成などを行います。ゲームサーバーがこの干渉に気付かない別のデータベースレプリカノード。データ アクセス レイヤーは、アプリケーションからデータベースへの呼び出しをデータベース ノード間で効率的に多重化することにより、データベース ノードで負荷分散を行うことができます (可用性と配置されたフェイルオーバー メカニズムにも依存します)。この話はもういいよ……。
いずれにせよ、私が書き留めたことの要約は、Mnesia をゲーム サーバーから分離することが重要だということです。これにより、サーバー アプリケーションを単独で管理し、後でデータ アクセスの分離を心配することもできます。データベースの物理レイアウトと論理レイアウトをプロジェクトの他の部分から分離すると、柔軟性と可用性が向上します。将来的には、データ アクセス層を変更せずに、データベースの設計などを変更できます。ゲーム ロジックを変更せずに、将来RiakやMembase Serverなどの別の DBMS に切り替えることもできます。
もう 1 つ: あちこちにスキーマをコピーすることは避けてください。最初からレプリケート/分散データベース アーキテクチャを設計します。クラスターになるために、ゲーム サーバーにノードからノードへ mnesia スキーマをコピーさせないでください。ゲームサーバーにゲームロジックなどを心配させ、データアクセスレイヤーにゲームデータを心配させます。そこにいくつかの啓発があります。成功!