Ситуация такая. Игровой портал, игра происходит на node.js, затем нода посылает данные на сервер php, а он в свою очередь просчитывает результат и делает записи в базу.
Как это выглядит:
Пользователи отыграли в игру, node.js послал массив пользователей с очками игры на сценарий php, php определил победителей и теперь необходимо сделать в базу кучу запросов:
1) достать данные игры и убедиться, что нам пришли правильные данные
2) записать в лог таблицу, что сыграна такая-то игра
3) сделать 4 запроса к каждому игроку:
- получить данные об игроке
- обновить рейтинг и тп
- сделать запись о том, что он сыграл игру (в 20:21 пользователь выиграл или проиграл и тп...)
- обновить данные
В игре может быть от 2 до 4 человек. Всего игр 10. В каждой игре может играть около 1000 человек.
По подсчетам, что бы обработать результат игры для 4 игроков нужно сделать около 20 запросов в базу данных.
Подскажите пожалуйста при росте посещаемости, как сервер отнесется к такой операции?
К примеру если одновременно будет сыгранно 100 партий в 10 играх. Серверу нужно будет сделать 2000 запросов в базу данных. Чем это черевато? И решит ли веб кластер проблему если она будет с нагрузкой?
Решать такие задачи надо использую планировщик очереди.
Создаешь задания сделать то и то, и бросаешь их в очередь.
А там уже может быть N воркеров, которые обрабатывают эту очередь.
Таким образом есть возможность сделать нагрузку на сервер не лавинообразной, а равномерной.
В зависимости от важности задачам можно давать разные приоритеты, и т.д.
Можно самому написать простейший обработчик очереди (складываем задания в БД и извлекаем и обрабатываем их оттуда N запушенными скриптами по крону, через какой то период времени).
Ну это, соответственно, будет верно если запросы будут оптимизироваными и легковесными. Одно дело 2000 запросов простых вставок/апдейтов, и другое дело 2000 запросов с кучей left join, подзапросов и временных таблиц.
Входящие данные заданы достаточно абстрактно. Какая БД, какой сервер. Что еще делает этот PHP сценарий. Очень много неопределенности.
Но если коротко: не должно этого быть много.
Во-первых, сильно влияет то, как спроектирована БД (здесь я имею в виду таблицы данных для хранения). Загляните внутрь любой современной CMS и увидите пачку в 20-30 sql запросов для формирования одной странице. И ничего, сайты тысячами запросы держат. (понятно, что кеширование как-то помогает, но все же.)
Во-вторых, можно оптимизировать запросы (на пример данные для игроков разом доставать за один запрос и т.п.)
Да и потом, можно исключить неравномерную нагрузку следующим образом — Нода пишет в файл. А php висит демоном, или дергается через равные (или динамически изменяемые) промежутки времени, и обрабатывает данные из файлов.
Временные таблицы могут создаваться неявно во время запросов.
Но в целом 2000 запросов по несколько милисекунд каждый задержку создадут, но совсем не критичную.
Ну подумает секунду-вторую, на многоядерном сервере скорее всего ничего заметно не будет.
Попробуйте с помощью ab поставить очередь из 100 конкурентных запросов на страничку которая будет делать фейковые запросы, посмотрите как себя поведет. Это десять минут на проверку, а мы тут гадаем на кофейной гуще.
СУБД бывают в двух типах:
- блокировочник: все обращения на сервер возвращают читаемое значение без всяких проблем. Скорость выполнения и логика работы очень простая. При изменении какой-либо записи, все операции временно блокируются, а потом продолжаются по окончании изменений.
- транзакционная модель: позволяет читать и изменять записи. Измененные записи создают временные копии, которые просто ожидают подтверждение или отмену этих изменений. Пока данные не подтверждены все другие записи видят только то, что было до изменений.
Средний
