является ли blease хорошим персистентным слоем для сервера игр Erlang? - PullRequest
5 голосов
/ 19 октября 2011

Я стремлюсь создать браузерную игру, в которой игроки могут создавать здания.

В каждом здании будет несколько модулей (двигатели, офисы, производственные линии, ...). Каждый модуль будет выполнять одно или несколько действий, например создание 2OO «предмета X» с ингредиентами Y, Z.

Игровой сервер будет настроен с использованием erlang: приложение OTP в качестве самого сервера и азот в качестве веб-интерфейса. Мне нужно постоянство данных. Я думал о следующем:

Когда кто-то или что-то взаимодействует со зданием или заканчивается таймер, представляющий некоторую производственную линию, супервизор порождает gen_server (если он еще не был создан), который загружает состояние здания из базы данных, поэтому gen_server может отвечать на сообщения например «добавить этот модуль», «запустить это действие», «сохранить эту продукцию на складе», «умереть» и т. д. (

Но когда здание не получает сообщений в течение X секунд или минут, оно завершает работу (благодаря функции времени ожидания gen_server) и возвращает свое текущее состояние обратно в базу данных.

Так что, поскольку это будет (мягкая) игра в реальном времени, gen_server должен быть настроен очень быстро. Я думал о мембране как о базе данных, потому что у нее очень хорошее время отклика.

Мой вопрос: когда сервер gen запущен, его состояния заполняют некоторую память, и это состояние присутствует в памяти, обрабатываемой также мембраной, поэтому состояние использует в два раза больше его размера в объем памяти. Это плохой дизайн?

Является ли мембрана хорошим решением для настойчивости в моем случае? было бы лучше использовать Mnesia или что-то еще?

Я боюсь ограничения размера таблицы Mnesia 2 Go (или 4?), Потому что в данный момент я не знаю среднего размера моего gen_servers (здания в этом примере, но также игроков, производственных линий и т. Д.), И у меня может быть когда-нибудь более 1 игрока:)

Спасибо

Ответы [ 2 ]

2 голосов
/ 22 октября 2011

Я согласен с Гинеком -Пичи- Выходил.Riak - отличная вещь для хранения ключей.

Мы используем Riak почти на 95% для того же, что вы описали.Пока все работает без проблем.В случае, если вы столкнетесь с ограничением производительности Riak - добавьте больше узлов, и это хорошо!

Еще одна интересная вещь в Riak - это очень низкое снижение производительности с течением времени.Вы можете найти больше информации о бенчмаркинге Riak здесь: http://joyeur.com/2010/10/31/riak-smartmachine-benchmark-the-technical-details/

Если вы используете его:

Об использовании мембраны и памяти: я также пробовал работать с мембраной, но обнаружил, что она не подходит для моих задач - (мембрана объявляет отказоустойчивость,Я не мог настроить его так, как он должен работать с ошибками, даже с помощью парней из состава мне не удалось).Поэтому на данный момент я использую следующую архитектуру: все игроки, которые находятся в сети и играют в игру, представлены как процессы игрока (gen_server).Все данные и бизнес-логика для каждого игрока находятся в процессе игрока.Время от времени каждый процесс игрока решает сохранить свое состояние в риаке.

Пока что это кажется очень быстрым и эффективным подходом.

Обновление: теперь мы работаем с PostgreSQL.Это круто!

0 голосов
/ 20 октября 2011

Вы можете использовать bitcask или другие Riak бэкэнды для хранения ваших данных. Избегайте IPC - это определенно хорошая идея, так что держите ее в Erlang.

...