Фон
В настоящее время мы работаем над стратегической веб-браузерной игрой, основанной на php, html и javascript.
План состоит в том, чтобы более 10 000 пользователей играли в одном мире.
В настоящее время мы используем memcached для:
- хранить статические данные json, языковые файлы
- хранить изменяемые сериализованные объекты класса php
(такие как армии, инвентаризации,
юнит-контейнеры, здания и т. д.)
В конце у нас есть сервер mysql, работающий и содержащий все данные игры. Когда объект загружается через наш ObjectLoader, он загружается в следующем порядке:
- проверяет статическую хэш-карту в
скрипт для объекта
- проверяет memcache, если он уже
был загружен в него
- в противном случае загружается из базы данных, и
сохраняет его в memcache и
статическая временная хэш-карта
Мы создали всю игру, используя объектно-ориентированный подход, при котором между объектами всегда создается функциональность. Из-за этого мы думаем, что нам удалось получить хорошую структуру, и с помощью memcached мы получили хорошие времена запроса от клиента-сервера при взаимодействии с игрой.
Я знаю, что memcache не синхронизируется, а также обычно не используется для хранения полной игры в памяти. В начале после запуска сервера время загрузки при загрузке объектов в memcache в первый раз будет высоким, но после того, как сервер некоторое время будет подключен к сети и большинство загрузок будет происходить из memcache, нагрузки будут значительно уменьшены.
В настоящее время мы сохраняем измененные объекты в memcache и базу данных одновременно. Ранее у нас была идея сохранять объекты в БД только через определенное время или через определенные промежутки времени, но из-за несогласованности риска, если memcache / server вышел из строя, мы пропустили его пока.
Клиентские запросы к серверу часто возвращают статус объекта в простом json-формате без изменения объекта, который, в свою очередь, визуально представлен в браузере с изображениями и javascript. Но время от времени, в зависимости от того, когда объект последний раз обновлялся, он обновляет их новой информацией (например, очередь сборки, содержащая запланированное время выполнения зданий, увеличивается, и / или массив запланированных элементов очереди изменялся).
Вопросы:
- Вы видите, как это может работать или
мы здесь ходим в слепоте?
- Ожидаете ли вы, что у нас будет много
проблемы несоответствия, если кто-то загружает
и обновляет объекты memcache
а кто-то еще делает то же самое?
- Возможно ли это сделать так, как это возможно?
он сделал это? Кажется работает
хорошо, но пока у нас есть только
было 4 человека онлайн в то же время
время ..
- Подходит ли какая-нибудь другая кеш-программа
для этого класс-объектного подхода, чем
Memcached?
- Есть ли еще какие-нибудь советы для этой ситуации?
UPDATE
Поскольку это просто «обычная веб-страница» (без апплета, флеш-памяти и т. Д.), Мы реализуем игру так, чтобы единственный сервер содержал «реальное игровое состояние»… состояние другого javascript -объекты на клиенте больше похожи на примерную версию игрового состояния сервера.
Время от времени и до того, как вы сделаете определенные важные вещи, визуальное состояние клиента обновляется до состояния сервера (например, клиент может выложить казармы, просит сервер построить бараки, сервер обновляет текущие ресурсы в соответствии с к данным о доходах на сервере и затем пытается построить казармы или бросает сообщение об ошибке, а затем отправляет текущее состояние сервера по ресурсам, зданиям обратно клиенту) ..
Это не стремительная игра, как настоящая стратегическая игра. Больше похоже на довольно медленную игровую игру на 3-4 месяца, где строительство может занять от 1 минуты до нескольких дней.