apc_store/apc_fetchのようなPHP Apache共有メモリストアには、良いFlask/Python/WSGIアナログがありますか？

Question

私はPHPで数年の大規模なゲームサーバー開発を行ってきました。ロードバランサは、着信要求をクラスタ内の1つのサーバーに委任します。より良いパフォーマンスの名前で、私たちはapc_storeとapc_fetchを使って、そのクラスタ内の各インスタンス上のすべての静的データ（本質的にゲーム世界のモデルオブジェクト）をApache共有メモリに直接キャッシュし始めました。

多くの理由から、Flaskマイクロフレームワークを使用して、Pythonで同様のゲームフレームワークを開発し始めています。一見すると、このインスタンスのメモリストアはPython/Flaskに直接変換されていないようなものです。 Memcachedを各インスタンスでローカルに実行することを検討しています（メインのMemcachedクラスタからかなり大規模なモデルオブジェクトをストリーミングするのを避けるため）。

代わりに何を使用できますか？

Answer 1

[5か月後]

私たちのゲームフレームワークは行われています。

最終的に、完全に初期化された各Webサーバーのsqlalchemyモデルインスタンスに静的データを格納することにしました。新しく起動したゲームサーバーがウォームアップしている場合、これらのインスタンスは共有されたMySQLデータベースを使用して最初に構築されます。

私たちのモデルファクトリはインスタンスプールに委ねられているので、モデルインスタンスはサーバごとに1回だけ構築する必要があります。これは重要です。これは、規模が大きくなると、 の目標であるではなく、アイテムコードを可能な限りアプリコードに近づけておくことで、このデータをワイヤレスでストリーミングすることはできませんでした。

私は、LAMPスタックとは異なり、Flaskサーバーがリクエスト間で実行し続けるため、サーバーのメモリ自体が「共有メモリ」であるため、私の元々の質問は素朴であることを認識しました.APCのようなものは必要ありません。実際には、何か要求処理スコープの外にあるそれ自身とFlask's threadsafe local storeは、 "共有メモリ"とみなすことができます。

Answer 2

私はこのケースでも、各サーバー上で一連の独立したキー/バリューストアシステムではなく、一元化されたキー/バリューストアシステムを持つことを検討したいと考えています。ロードバランサが常に同じサーバーに同じユーザーをリダイレクトしない限り、ユーザーの要求が別のサーバーにルーティングされるたびに、各ノードは共有キャッシュからアクセスするのではなく、ゲームの状態を取得する必要があります。

また、各システムのローカルキー/バリューストアが発生する可能性のあるメモリストレインによって、ゲームサーバーの他の機能が低下する可能性があります。それは主にキャッシュされるデータの量に依存します。

一般に、最良の方法は、memcachedクラスタでどのようなパフォーマンスが得られるか、保存するオブジェクトの種類とローカルストレージの違いを確認するためのベンチマークを実行することです。

キー/バリューストアに必要なその他の機能に応じて、mongodb（http://www.mongodb.org /）のようないくつかの選択肢を調べることもできます。