我已经用 PHP 完成了几年的大型游戏服务器开发。负载均衡器将传入请求委托给集群中的一台服务器。为了更好的性能，我们开始在集群中的每个实例上缓存所有静态数据（本质上是游戏世界的模型对象），直接在 Apache 共享内存中，使用apc_store和apc_fetch.
出于多种原因，我们现在开始使用 Flask 微框架在 Python 中开发类似的游戏框架。乍一看，这个实例的内存存储似乎不能直接转换为 Python/Flask。我们目前正在考虑在每个实例上本地运行 Memcached（以避免从我们的主 Memcached 集群通过网络传输相当大的模型对象。）
我们可以用什么代替？
我认为即使在这种情况下，您也可能需要考虑拥有一个集中的键/值存储系统，而不是在每台服务器上使用一系列独立的系统。除非您的负载均衡器总是将相同的用户重定向到相同的服务器，否则您可能会遇到用户的请求每次都被路由到不同的服务器的情况，因此每个节点都必须检索游戏状态，而不是从共享缓存中访问它。
此外，每个系统上的本地键/值存储可能会导致内存紧张，这可能会减慢游戏服务器的其他功能。尽管这在很大程度上取决于缓存的数据量。
一般来说，最好的方法是运行一些基准测试，看看你使用 memcached 集群可以获得什么样的性能，以及你存储的对象类型与本地存储的对比。
根据您希望从键/值存储中获得的其他功能，您可能还想研究一些替代方案，如 mongodb ( http://www.mongodb.org/ )。
[五个月后]
我们的游戏框架就完成了。
最后，我们决定将静态数据存储在每个 Web 服务器中完全初始化的 sqlalchemy 模型实例中。当新启动的游戏服务器正在预热时，这些实例首先通过访问共享的 MySQL 数据库来构建。
Since our Model factories defer to an instance pool, the Model instances need only be constructed once per deployment per server – this is important, because at our scale, MySQL would weep under any sort of ongoing load. We accomplished our goal of not streaming this data over the wire by keeping the item definitions as close to our app code as possible: in the app code itself.
I now realize that my original question was naive, because unlike in the LAMP stack, the Flask server keeps running between requests, the server's memory itself is "shared memory" – there's no need for something like APC to make it so. In fact, anything outside of the request processing scope it self and Flask's threadsafe local store, can be considered "shared memory".