Синхронный и асинхронный доступ к базе данных
Я хочу разработать сложную игру с, возможно, тысячами функций и вызовов базы данных.
Мне интересно, действительно ли необходимо выполнять мои запросы к базе данных в асинхронном режиме. Его боль в коде, и все мои функции должны будут использовать обратные вызовы вместо clean return
метод. Это нормальный подход?
действительно ли кодирование этих вызовов в async намного быстрее, учитывая, что база данных MySQL обрабатывает один запрос за раз?
5 ответов
Если что-то не изменилось радикально в узел.JS в последнее время, вы в значительной степени вынуждены использовать асинхронный доступ к базе масштабирование с все ваши запросы пользователей будут выполняться на один поток и синхронное ожидание базы данных действительно снизит вашу производительность. Если один пользователь выполняет медленную операцию, всем остальным пользователям придется подождать, пока она не будет выполнена.
узел.JS действительно построен для асинхронного события поток, вы получите гораздо лучшую производительность, работая с ним, чем работая вокруг него.
асинхронный запрос не быстрее, чем синхронные, независимо от того, как вы их делаете, они все равно делают то же самое. Единственное, что меняется, это скорее вы блокируете запрос или нет.
когда вы идете с синхронным методом, который сделал запрос, остановит его выполнение, ожидая возврата запроса, только когда это будет выполнено, он продолжит свое выполнение. Хотя при использовании асинхронного запроса нет необходимости ждать, пока запрос завершите, вы можете jut продолжать, и когда это будет сделано, будет вызван обратный вызов.
другое дело, что обычно база данных является узким местом, когда приложение делает много вызовов СУБД, из-за этого вы можете рассмотреть возможность использования кэширования come для уменьшения загрузки из СУБД.
скорость Database engine + время передачи будет в значительной степени одинаковым в любом случае. Проблема в том, что асинхронные вызовы не блокируют вызывающего абонента. Таким образом, асинхронная арка-это способ пойти для любых систем "реального времени", которые должны быть высоко реагирующими на другие входы. (Например, игры, которые всегда должны быть очень отзывчивыми к человеку.)
запросы будут поставлены в очередь на уровне базы данных в MySQL. Есть намного больше вариантов, если вы можете подумать об использовании Mongo DB для некоторых ваших данных.
Как и Ницан, вы должны знать, что " асинхронный запрос не быстрее синхронных, независимо от того, как вы их делаете, они все равно делают то же самое."
никто не говорил, но если есть много пользователей и много запросов, у вас других решений для ограничения доступа к базе данных :
создать кэш-файлы
и обновите их действиями пользователей или задачами CRON.
- пользователи информация
- предупреждает пользователей
- пользователи действиях
- пользователи инвентаризации ...
заполненный процесс базы данных
для некоторых повторяющихся запросов вы можете запасти их в MySQL. Они будут выполняться быстрее, чем запрос пользователя.