Comments 23
Спасибо за статью, интересная. Есть вопрос: почему бы в качестве промежуточного звена не использовать, к примеру, Redis — он тоже хранит данные в памяти, их можно один раз туда загрузить и потом по таймауту выгрузить?
denis_g +100500
Двумя руками — ЗА!
Двумя руками — ЗА!
На каждое действие пользователя надо будет достать профиль из редиса, раскодировать, сделать полезную работу, закодировать и положить в редис. Получаются большие накладные расходы
Ну, тут уже все зависит от конкретной реализации профиля — если там многоуровневая JSON-структура, то тогда да, расходы большие, но если там обычный словарик, который записывается в Redis'овский hash или бинарная структура, которая хранится просто как последовательность байт, то накладные расходы не должны быть слишком уж большими. Кроме того, Redis умеет делать атомарные инкременты, что позволяет производить, например, учет статистики вообще без чтения из БД, а самое главное — поддерживает server-side scripting, который также может избавить от необходимости гонять данные туда-сюда в некоторых случаях.
Часто 1 реквест по сети стоит дороже чем вся бизнес логика. Если производительность для вас важна конечно.
Зачем по сети? Не надо по сети. Можно Redis на той же машинке поднять и ходить к нему через unix domain socket.
Зачем тогда использовать редис, если он будет стоять на той же машине где и испольняемая программа?
Например, чтобы избежать такого варианта развития событий. Плюс все-таки потенциальная возможность работы по сети (если нужно будет ее использовать в ущерб производительности).
Собственно, мой первоначальный вопрос сводился не к утверждению «технология А лучше технологии Б, надо было вам использовать технологию А», а к вопросу «рассматривали ли вы технологию А и если да, то почему не стали ее использовать?». Т.е. интересно было узнать, почему именно Erlang, а не Redis, memcached или еще какая-нибудь in-memory БД.
Собственно, мой первоначальный вопрос сводился не к утверждению «технология А лучше технологии Б, надо было вам использовать технологию А», а к вопросу «рассматривали ли вы технологию А и если да, то почему не стали ее использовать?». Т.е. интересно было узнать, почему именно Erlang, а не Redis, memcached или еще какая-нибудь in-memory БД.
Например, чтобы избежать такого варианта развития событий
Ну так редис тут не поможет, потому что если он не скинул данные на диск, в момент когда отрубилась машина, то данные точно так же будут потеряны.
потенциальная возможность работы по сети
Ну это уже premature optimization.
У такого подхода, кроме больших накладных расходов, есть еще несколько серьезных недостатков. Первый это по какому событию копировать профиль из редиса в основную базу. Нужно гдето заводить таймер активности игрока. Получается много много таймеров. Опять же их удобно сделать на эрланге, но что мы получим. Мы получим снова по процессу на пользователя, так зачем если уже есть процесс, хранить отдельно данные. Второе, такая реализация банально сложнее.
я правильно понял что для 50 тыс онлайн пользователей нужно 50 тыс процесов? ОСь не повесится?
Выглядит красиво, до тех пор пока не начнете реализовывать. Процесс взаимодействия игроков выглядит не совсем так. Что будет например если игрок А хочет что-то сделать с игроком Б, когда тот в оффлайне. Поднимать весь процесс игрока Б для одного действия? А если нужен внутре-игровой рынок предметов, личные сообщения, форум, фиксация онлайн, топы (отдельный проект требующий БД ?). 50 000 тыс онлайн на одном сервере — допустим, а если 500 000 тыс? Я не в курсе насчет ерланга, но что будет при взаимодействие двух процессов находящиеся на разных узлах (физ. машинах), не плохо если сервера находятся в одной стойке, а если в разных ДЦ? Вы пробовали использовать что нибудь сетевое-асинхроное-джиттируемое + сервис очередей + масштабируемые-из-коробки БД типа (couchbase (не couchDB), mongo, redis и т.д.), хотелось бы узнать какие проблемы могут поджидать при таком подходе?
Некоторы вообще не убивают процессы оффлайновых игроков. Ну висит себе игрок со статусом offline, и висит. память жрет, CPU нет. Зато работать с ним очень удобно.
> Я не в курсе насчет ерланга
ну вот, видимо, сначала неплохо было бы покурить немножко эрланга, прежде чем бросаться с критикой «Выглядит красиво, до тех пор пока не начнете реализовывать».
> Я не в курсе насчет ерланга
ну вот, видимо, сначала неплохо было бы покурить немножко эрланга, прежде чем бросаться с критикой «Выглядит красиво, до тех пор пока не начнете реализовывать».
Как игрок не проявляет активности некоторое время, пусть 10 минут, сохраняем профиль в базу и завершаем процесс
Как я понимаю, если сервер в течение этих 10 минут приляжет отдохнуть, то весь мой игровой прогресс, как и прогресс N тысяч других игроков, уйдет в небытие?
Раз так, то зачем вам база вообще? Если уж решили уйти от ынтерпрайза, то до конца. Профиль юзера можно просто в файл скидывать. Хоть в джейсоне, хоть в бинарном формате.
Выбор Ерланга тоже совсем не оправдан. У меня такой же подход. 2.5к человек онлайн создают нагурзку 20к рек-сек… Все это на виртуалке с 2-мя 2.2Гц ядрами и на «тормозной яве» с асинхронными сокетами.
Выбор Ерланга тоже совсем не оправдан. У меня такой же подход. 2.5к человек онлайн создают нагурзку 20к рек-сек… Все это на виртуалке с 2-мя 2.2Гц ядрами и на «тормозной яве» с асинхронными сокетами.
А можно поподробнее о базе данных? Что в итоге взяли, и какое DAU/MAU оно вытягивает, и как при этом загружено?
Насчет того, что Erlang «достаточно честно использует память» это совсем неправда. У Erlang довольно сложный многослойный аллокатор памяти, так что фрагментация может съедать до 50%.
Например у меня сейчас запущено приложение, работает около 15 дней, в HTOP отображается 153Мб, изнутри же
Т.е. 56Мб всего «полезной нагрузки». Это всё конечно можно подтюнить, но верным ваше утверждение от этого не станет.
Например у меня сейчас запущено приложение, работает около 15 дней, в HTOP отображается 153Мб, изнутри же
1> memory(total). 61631088
Т.е. 56Мб всего «полезной нагрузки». Это всё конечно можно подтюнить, но верным ваше утверждение от этого не станет.
Sign up to leave a comment.
Наш доклад на «Стачке»: «Как избавиться от persistent database зависимости»