Я сделал пару лет крупномасштабной разработки игрового сервера в PHP. Балансировщик нагрузки делегирует входящие запросы на один сервер в кластере. Во имя лучшей производительности мы начали кэшировать все статические данные (по существу, объекты модели игрового мира) в каждом из экземпляров этого кластера, непосредственно в общей памяти Apache, используя apc_store и apc_fetch.
По ряду причин мы теперь начинаем разрабатывать аналогичную игровую среду на Python, используя микрофрейм Flask. На первый взгляд, это хранилище памяти экземпляра - это один кусок, который, как представляется, не переводится непосредственно в Python/Flask. В настоящее время мы рассматриваем возможность запуска Memcached локально в каждом экземпляре (чтобы избежать потоковой передачи довольно крупных объектов модели по проводу из нашего основного кластера Memcached.)
Что мы можем использовать вместо этого?
Ответ 1
[Пять месяцев спустя]
Наша игровая среда выполнена.
В итоге мы решили сохранить статические данные в полностью инициализированных экземплярах модели sqlalchemy на каждом веб-сервере. Когда вновь загруженный игровой сервер разогревается, эти экземпляры сначала создаются путем нажатия на общий MySQL db.
Поскольку наши фабрики Model откладываются к пулу экземпляров, экземпляры модели нужно создавать только один раз для каждого развертывания на сервер - это важно, потому что в нашем масштабе MySQL плачет под любой постоянной нагрузкой. Мы выполнили свою задачу: не передавать эти данные по проводнику, сохраняя определения элементов как можно ближе к нашему приложению: в самом коде приложения.
Теперь я понимаю, что мой первоначальный вопрос был наивным, потому что, в отличие от стека LAMP, сервер Flask работает между запросами, сама память сервера является "общей памятью" - нет необходимости в чем-то вроде APC, чтобы это сделать. Фактически, все, что находится вне области обработки запроса, оно само и Flask threadsafe локальное хранилище, может считаться "общей памятью".
Ответ 2
Я бы подумал, что даже в этом случае вы можете захотеть иметь централизованную систему хранения ключей и значений, а не ряд независимых на каждом сервере. Если ваш балансировщик всегда переадресовывает одних и тех же пользователей на одни и те же серверы, вы можете запускать случай, когда запросы пользователя маршрутизируются на разные серверы каждый раз, поэтому каждый node должен будет получить состояние игры вместо доступа к нему из общего кеша.
Также напряжение памяти, которое может иметь локальное хранилище ключей/значений в каждой системе, может замедлить работу других игровых серверов. Хотя это во многом зависит от количества кэшируемых данных.
В целом наилучшим подходом было бы запустить некоторые тесты, чтобы узнать, какую производительность вы получите с кластером memcached и типами объектов, которые вы храните, и локальное хранилище.
В зависимости от того, какие другие функции вы хотите от вашего хранилища ключей/значений, вы также можете изучить некоторые альтернативы, такие как mongodb (http://www.mongodb.org/).
