PHP で大規模なゲーム サーバーの開発を数年間行ってきました。ロード バランサーは、着信要求をクラスター内の 1 つのサーバーに委任します。パフォーマンスを向上させるために、 と を使用して、そのクラスタ内の各インスタンスのすべての静的データ (基本的にはゲーム ワールドのモデル オブジェクト) を Apache 共有メモリに直接キャッシュし始めましapc_storeたapc_fetch。
さまざまな理由から、Flask マイクロフレームワークを使用して、Python で同様のゲーム フレームワークを開発し始めています。一見すると、このインスタンスのメモリ ストアは、Python/Flask に直接変換されないように見える 1 つの部分です。現在、各インスタンスでローカルに Memcached を実行することを検討しています (メインの Memcached クラスターからネットワーク経由でかなり大きなモデル オブジェクトをストリーミングしないようにするためです)。
代わりに何を使用できますか?
この場合でも、各サーバーに一連の独立したキー/値ストア システムを配置するのではなく、集中型のキー/バリュー ストア システムを使用することを検討することをお勧めします。ロードバランサーが常に同じユーザーを同じサーバーにリダイレクトしない限り、ユーザーのリクエストが毎回異なるサーバーにルーティングされるため、各ノードは共有キャッシュからアクセスする代わりにゲームの状態を取得する必要があります。
また、各システムのローカル キー/バリュー ストアで発生する可能性のあるメモリ負荷により、ゲーム サーバーの他の機能が遅くなる可能性があります。ただし、キャッシュされるデータの量に大きく依存します。
一般に、最善の方法は、いくつかのベンチマークを実行して、memcached クラスターでどのようなパフォーマンスが得られるか、および保存しているオブジェクトの種類とローカル ストレージを比較することです。
キー/値ストアに必要な他の機能に応じて、mongodb ( http://www.mongodb.org /) などの代替手段を検討することもできます。
【5ヶ月後】
ゲームのフレームワークが完成しました。
最終的に、各 Web サーバーの完全に初期化された sqlalchemy モデル インスタンスに静的データを格納することにしました。新しく起動したゲーム サーバーがウォームアップするとき、これらのインスタンスは共有 MySQL db をヒットすることによって最初に構築されます。
モデル ファクトリはインスタンス プールに従うため、モデル インスタンスはサーバーごとのデプロイごとに 1 回だけ構築する必要があります。このデータをネットワーク経由でストリーミングしないという目標を達成するために、アイテムの定義をできるだけアプリ コードに近づけることで実現しました。つまり、アプリ コード自体です。
LAMPスタックとは異なり、Flaskサーバーはリクエスト間で実行され続け、サーバーのメモリ自体は「共有メモリ」であるため、元の質問が単純だったことに今気づきました.APCのようなものは必要ありません。実際、リクエスト処理の範囲外のものと、Flaskのスレッドセーフなローカル ストアは、「共有メモリ」と見なすことができます。