Высоконагруженный сервер и статистика по нему

В общем интересуют общепринятые решения, которые обеспечивают малозатратную процедуру сбора статистики на игровом сервере (допустим, он пока только один — не кластер). А именно: юзеры подключаются к многоигровому серверу, играют, при этом все их действия фиксируются для дальнейшего предоставления отчётов, etc.

Что для этого использовать? БД в отдельном потоке? Как-то ненадёжно выглядит. Redis? Быстро, но не очень удобно. Может MongoDB в основном потоке или ещё какую NoSql?

Сейчас используются PostgreSQL и redis, но не для сбора статистики, а других нужд, и в основном при логине/разлогине юзеров.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: highload, сервер, статистика

Ctrl + Enter

Олексій Пєніє 19.07.2014 00:18

Вообще-то тот случай, когда статистику по конкретному юзеру стоит считать прямо в игровом клиенте. Для верности сделать обфускацию кода. И уже сама клиентская часть снабдит тебя самой любопытнейшей статистикой.

В дальнейшем реализуешь как отдельный плагин или скрипт к клиентской части.

База данных — обычный примитивный SQL. Как правило тебе быстрая статистика не нужна, а потому пусть клиент сам её отправляет по факту завершения сесии, раз в сутки, или как тебе удобно.

Собственно говоря, логин-разлогин как раз та процедура, на которую можно это счастье повесить. Прямо в ту же базу, отдельной табличкой. Она прекрасно структурируется, не содержит лишней инфы. А если уже в будущем захочешь дико расширенной статистики по юзерскому поведению внутри игры [а это нечасто надо] или по багам — то на том же сервере сделаешь отдельную очередь парсинга этих пакетов. Почему отдельную: а наверняка захочешь баг-трекинг, и он может очень сильно перегрузит поток из-за кривых ручек программиста клиентской части, ты же не хочешь чтобы логин/разлогин при этом упал?

Если двумя словами — не делай статистику хайлоадом. Это не ценная информация, ею можно смело рисковать в рамках одного юзера. Потому считай её прямо на юзере, проверяя свежесть версии в момент логина. И пусть он тебе её неспешно отсылает. А вот КОГДА её отослать и по какому принципу — это уже решает подгружаемый код. Например, когда ты хочешь потестить новшество, и опросить всего 1000 юзеров играющих более месяца.

В будущем ты наверняка захочешь делать юзеру какие-нибудь предложения рекламного характера. И вот здесь и есть основное применение статистики. То есть, именно плагин статистики при отсылке в ответ может получить список идентификаторов, по которым он должен обратиться за получением рекламы.

Но опять же, это по возможности не хай-лоад. Иначе рискуешь из-за ошибки в коде задолбать юзера рекламой — это может [наверняка] спровоцировать отказ юзера от игры. Другими словами, он зашёл поиграть, снять стресс, расслабиться — а ты его хайлоадишь.

Так что, оставь как есть. Время покажет что ничего менять не надо, лишь немного оптимизировать с годами.

Відповісти

Підтримати

Макс Матюхин программист в Badoo 22.06.2014 22:08

если речь идёт о бизнес-статистике, то такие события логируем в scribe. Он эти события переносит на другой сервер, а там они уже агрегируются (если надо) и складываются куда надо — mysql, hadoop — сильно зависит от требований.

Если надо рисовать realtime статистику производительности сервера чтобы следить за нагрзукой — число запросов в секунду, потребление памяти, cpu, как часто сервер общается с БД и другими внешними источниками — используем pinba (pinba.org) + графики через rrdtool

Andrii Podanenko gestalt therapist, team lead, architect, CEO в ITCare, LLC 20.06.2014 23:28

munin + custom plugins

Олександр Мацько Тренер в Proficenter Soft 20.06.2014 14:15

Надо бы указать планируемый req/sec, количество и тип параметров собираемой статистики.
А так, в общем, Redis на первоначальном этапе. Особенно, учитывая ограничение на железо.
Mongo — при росте, увеличении количества собираемых данных, усложнении системы.
Еще позже — система на 2 хранилищах: оперативном (Redis или Mongo) и агрегированном (Mongo, SQL-like).

Igor Petruk Software Engineer в Google 20.06.2014 14:04

Да пишите ее уже батчами (преагрегировано) одними appendами в файл, а потом его заливайте на сервера статистики и там аггрегируйте. Так можно столько статистики собрать, что вам и не снилось. Будет чуть-чуть отставать по времени, но это же статистика

anonymous 20.06.2014 13:02

Redis, почти все кто работал в хайлоаде рекомендуют именно его.

Bohdan Chechyn SSE в BeReal 20.06.2014 12:46

рекомендую обратить внимание на касандру, она вроде довольно шустро справляется с такого рода задачами и она надёжна
сам правда пока не пользовался, только читал много всякого:)

Сергій 20.06.2014 13:16

cassandra для одного сервера — это слишком много. redis, statsd

Bohdan Chechyn

Андрей Кобышев Middle Python Web Developer в Freelance 20.06.2014 12:37

Я бы юзал redis. А что в нем неудобно?

Sergei Beloborodov blockchain dev 20.06.2014 12:39

примитивные «ключ-значение» пусть даже с хешами и т.п. Всё равно таблицы удобнее.

Андрей Кобышев

Высоконагруженный сервер и статистика по нему

10 коментарів

Підписатись на коментарі