Как работать с большим количеством запросов?

Question

[ivandao]

В базе есть у пользователя определенная сумма средств. По запросу фронта ты эту сумму увеличиваешь на 10 рублей и более ее увеличивать нельзя, но если выполнить ботом сразу же 1000 запросов, то сумма увеличится на 10 тысяч рублей и будет закрыта только через какое-то время. Как это исправить?

Comments

[VitalyChaikin]

нужно перенести проверку "более ее увеличивать нельзя" на бек (при записи)

[Ромзес Панагиотис]

А где код?

[Ev Gen]

кто и как будет закрыта?

Answer 1

[Дмитрий Шицков]

Использовать транзакцию и выполнять блокировку строки таблицы на запись перед увеличением значения

Comments

[Иван Шумов]

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

Если же просто делать транзакции как обычно это происходит то они все-равно выполнятся позже, просто сумма будет поменьше по тому что произойдет параллельное чтение состояние и кто-то получит одну информацию, а кто-то другую

[Дмитрий Шицков]

Иван Шумов, Вопрос, к сожалению, не содержит достаточно конкретной информации о реализации. Если суть проблемы в том, чтобы не позволить одному и тому же пользователю дважды изменить сумму, то должно быть достаточно SELECT ... FOR UPDATE (приведет к блокировке других операций чтения для данных строк с FOR UPDATE) по id пользователя + id того кто выполнил запрос, а затем выполненить операцию по увеличению суммы. Порядок исполнения транзакций, судя по задаче, не важен.

Answer 2

[StiflerProger]

Просто каждый запрос делай в транзакции с "select for update".
1. Сразу после получения запроса ставишь блок "select for update".
2. Проводишь валидацию данных. Проверяешь оплату в другой таблице и тп.
3. Добавляешь 10 рублей юзеру.

Если у тебя юзер может даже после этого добавить себе 1000 раз по 100 рублей, то проблема в шаге #2.
Т.е. твой момент с "более ее увеличивать нельзя" должен проверяться в шаге #2.

Answer 3

[Developer]

но если выполнить ботом сразу же 1000 запросов, то сумма увеличится на 10 тысяч рублей

Такое возможно, если код писал джуниор и вылил в продакт без ревью лидом. Но если у джуна такие права на CI/CD, то тут вопросы к менеджменту и админам

Comments

[d'Ivan]

Этот ответ ничем не помогает автору вопроса. Если есть опыт, то лучше поделиться им, чтобы помочь решить задачу.

Answer 4

[Иван Шумов]

Очереди. По сути есть 2 варианта:

• Простой. Мы создаем очередь и в ней обрабатываем последовательно все операции одним обработчиком без масштабирования. Подойдет для старта на небольших нагрузках
  
• Сложный. К простому варианту добавляем слово Kafka и партицирование по ключу клиента чтобы команды от одного клиенты попадали в одну партицию топика. Надо иметь больше опыта, но зато на больших объемах отлично масштабируется
  

Comments

[Ромзес Панагиотис]

Но это же не решит вопрос насчет однократного добавления на 10 рублей. Просто очередь разрулит ожидание блокировки СУБД и будет поочередно добавлять 1000 раз по 10 рублей.
Вопрос, по-моему, не про то как держать нагрузку при конкурентных запросах, а про махинации с суммами.

[Иван Шумов]

Ромзес Панагиотис, но деньги же не из воздуха берутся) запросы пользователь может сколько угодно формулировать, но пользователи деньги же не печатают. Очередь как раз позволит каждую операцию начинать с чистого состояния и все четко провалидировать

[Ромзес Панагиотис]

Иван Шумов, мне кажется, что автору вопроса интересен сам механизм валидации.

[Надим]

Очередь хороший вариант. Еще можно переписать фронт на JavaScript, он однопоточный и в нем исключены ситуации, когда чтение / запись происходят одновременно несколько раз.

Answer 5

[Сергей Соколов]

добавить признак / колонку в БД «больше обновлять нельзя».
При обновлении проверять этот признак и устанавливать его в положение «баста»:

UPDATE accounts 
SET money = money + 10, isUpdateable = false
WHERE id = :uid 
  AND isUpdateable = true

Успешное обновление прикрывает лавочку.

В вопросе стоило уточнить, конечно, что за «база» – вдруг это и не SQL, а кластер Redis на множестве узлов.