Почему async функции багаются быстрыми запросами? Как доработать?

Question

[Карлиндоу Мэрлифи]

Привет всем.
Есть веб-приложение(сайт) на node.js использую express

Суть проблемы в том что, что при очень быстрой отправке запросов от одного пользователя, на сервере эти запросы обрабатываются беспорядочно.

Здесь я максимально упростил код и смоделировал ситуацию
Допустим есть

код

const max_clicks = 30;
router.get('/something', async (req, res) => {
    let clicks = await // запрос в бд, который вернёт текущее количество кликов
    if(clicks < max_clicks ){
        await clickPlus(); // запрос в бд, который прибавляет один клик
    }
    res.render... // для приличия вернём что-нибудь
});

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

p.s проблема не конкретно с кликами, я для наглядности так описал

Comments

[Kentavr16]

Не отправлять ни в коем случае кучу запросов . Считать на клиенте.

[Карлиндоу Мэрлифи]

Kentavr16, какой-то странный совет, это же не решение проблемы, а лишь ограничение

[Kentavr16]

Карлиндоу Мэрлифи, ты сам создаёшь себе проблему. Потому что не зря операция await так называется. Буду возле ПК отвечу если до этого не напишут.

[WbICHA]

Карлиндоу Мэрлифи, тем не менее это самое простое решение. Добавь тротл/дебоунс со стороны клиента.
Впрочем, на сервере тоже лучше ограничения поставить, ограничь количество запросов для пользователей в секунду, можешь ещё в очередь запихать запросы, если очень надо их так обрабатывать.

[Карлиндоу Мэрлифи]

WbICHA, в ноде ограничить или на уровне nginx? и как именно ограничить? буду рад даже ссылкам на доки. я просто впервые слышу тротлинге и дебаунсах

[Kentavr16]

Карлиндоу Мэрлифи, погоди, быстрая отправка большого количества запросов это проблема вызывающая баг или ты ХОЧЕШЬ чтобы пользователь отправлял много запросов, но это не получается?

[Карлиндоу Мэрлифи]

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

[Карлиндоу Мэрлифи]

Kentavr16, я наверно решу эту проблему так,
для пути /something создам массив , куда буду ставить айди пользователей.
и при выполнении запроса буду добавлять айди игрока в массив а при завершении убирать оттуда.
И если запрос отправлен, когда предыдущий ещё не обработался, буду просто редиректить

[Kentavr16]

Карлиндоу Мэрлифи, ну тогда все верно. Вариант первый - дебоунс. Вариант с ограничением на сервере - написать свой мидлвер в случае с экспрессом или использовать что-то вроде такой библиотеки.

[Карлиндоу Мэрлифи]

Kentavr16, express-rate-limit я пробовал, оно не решает эту проблему, а лишь ограничивает, причём не точечно, вот с массивом получилось, наверно так и буду дальше в случае необходимости делать

[Kentavr16]

Карлиндоу Мэрлифи, Я вот о чем - если много-много запросов к серверу это норма для того кода который ты пишешь (например, кликер условный),то клики нужно считать на клиенте, а не засорять канал запросами на каждый чих. а к серверу обращаться только для синхронизации. Или вообще перейти на сокеты, которые выглядят логичным решением для постоянного соединения.

[Карлиндоу Мэрлифи]

Kentavr16, ты совершенно прав.
Кстати, к этой ситуации применимы также сокеты.
При обмене сообщениями через вебсокеты, где на сервере надо выполнить определенную функцию, тоже будет такая проблема, как с запросами, и там тоже я бы создал массив, как на примере выше, хотя на тот момент, когда на вебсокетахтакая проблема была я решал её очередью запросов. Просто в очередь ставил, если предыдущее не выполнилось ещё, но я не уверен, лучшее ли это решение

[Карлиндоу Мэрлифи]

Карлиндоу Мэрлифи, вообще чем отдельный массив для каждого пути делать, лучше какую-нибудь обёртку написать для этого с ключами. полагаю, что все те кто сталкивался с такой проблемой так и делали

[WbICHA]

Карлиндоу Мэрлифи, вебсокеты тебе здесь не помогут, у тебя бутылочное горлышко здесь — обращение к базе. В остальном Kentavr16 всё хорошо расписал.

вообще чем отдельный массив для каждого пути делать, лучше какую-нибудь обёртку написать для этого с ключами. полагаю, что все те кто сталкивался с такой проблемой так и делали

Естественно, обёртки наше всё.

[Lynn «Кофеман»]

14 ответов и ни одного упоминания что это надо делать в БД.
Гуглить слова: транзакция и блокировка (lock)

[Карлиндоу Мэрлифи]

Lynn «Кофеман», интересно, сейчас разузнаю

[szQocks]

Карлиндоу Мэрлифи, очереди, лимиты энпоинтов, капча, дебоунс

[Lynn «Кофеман»]

Карлиндоу Мэрлифи, ну посмотрим что вы скажете когда вам понадобиться горизонтальное масштабирование…

[WbICHA]

Lynn «Кофеман», ну, извиняюсь, серьёзно базы никогда не трогал.) Впрочем, локи скорее дополнение ко всему вышесказанному, чем замена. Хотя хэндмейд очереди запросов можно заменить, вроде.

[Карлиндоу Мэрлифи]

кароче, тот способ, что я описал не панацея.
Действительно решает эту проблему лишь блокировка запросов на уровне БД.
Так что, как сказал Lynn «Кофеман»,
нужно изучить транзакции для постгреса