Laravel как правильно обновить баланс при покупке?

Question

[Валерий Павлов]

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

Есть сайт. На нем есть покупка товара (чего - не важно).
Есть контролер, в нем метод buyProduct(). Там все по дефолту, сначала идут разные проверки (хватает ли баланса, есть ли еще товар, не заблочен ли юзер и т.п.).

Если все проверки проходят, идет try catch блок с beginTransaction, commit-ом в случае успеха ну и rollback в случае ошибки.

Всего идут 3 sql запроса (через конструктор запросов Laravel).
1 - Занесение инфы в таблицу buyHistory.
2 - Занесение инфы в таблицу historyPayment (история оплат, не так важно зачем мне она, просто говорю все как есть).
3 - Уменьшение баланса юзера на цену товара.

Проблема с третим пунктом. Раньше я обновлял баланс так:

$user->balance -= $price;
$user->saveOrFail().

Но была проблема с тем, что когда очень быстро отсылаешь запросы на покупку (у сайта есть API, через него можно покупать). То бывал часто баг, когда баланс еще не успевал минуснуться, уже шел новый запрос. Сайт думал что баланса хватало и выдавал еще один товар (хотя по факту денег уже не хватало, не успевал пройти запрос).

Я пофиксил это легко - сделал так:
$user->dispatch('balance', $price);

И все стало просто круто, все работало. Но сейчас проблема появилась опять.
(довольно много юзеров на сайте, а не давно еще вырос онлайн). Просто если раньше словить баг было очень легко и наабузить себе баланс. То сейчас чуть сложнее, нужно еще быстрее обновлять страницу и где-то 1 попытка из 3 сработает.

Я вывел лог, проблема таже - не успевает минуснуться баланс.
Мне нужна подсказка: как правильно построить эту систему покупки, чтобы все было хорошо?

Comments

[Виталий Артемьев]

Я для решения проблемы конкурентных запросов использовал рекомендательные блокировки от PostgreSQL
https://postgrespro.ru/docs/postgresql/12/function...

Может в mysql есть что-то подобное

Answer 1

[Дмитрий]

1. Лочить запись в таблице балансов до момента списания. Залочили, проверили, списали, разлочили. Другие процессы либо будут ждать - либо вылетят по таймауту.

2. Использовать update с условием. update user_balance where user_id = ? and balance > нужного. У вас запрос не выполнится если кто то уже списал деньги. А вы по affected rows можете судить списалось или нет

Comments

[Алексей Уколов]

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

[Дмитрий]

Алексей Уколов, я честно говоря не встречал проблем.

[Валерий Павлов]

Можешь про первый способ подробнее расписать? Как лочить правильно?

[Алексей Уколов]

Дмитрий, вполне возможно, сейчас уже всё ок. Или у меня тогда была слишком замудрёная логика нужна, я уже не помню. Лет восемь назад я столкнулся с проблемами на Mysql ~5.0 и с тех пор просто использую внешние локи.

[Дмитрий]

Иван,

\DB::transaction(function() use($balance_id) {
    $balance = \App\Models\Balance::lockForUpdate()->find($balance_id);
    if($balance->balance > 10){
        //do stuff
    }
)};

https://laravel.com/docs/9.x/queries#pessimistic-l...

[Дмитрий]

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

[Алексей Уколов]

в более менее серьезных системах в эту бд вносят изменения сотни приложений

Ну, это, мягко говоря, огромное преувеличение :)

Но да, всё верно, это может быть существенным недостатком.

[Алексей Уколов]

lockForUpdate()

А, ну вот, теперь я чего-то вспоминаю. Там же нет механизма разлочивания - оно автоматическое, правильно? Вот у автора три запроса. И может быть такое, что на все три должен быть один лок, согласно логике приложения. Вроде, такое средствами СУБД нельзя реализовать?

[Валерий Павлов]

Алексей Уколов, Кстати да, логично что должно быть три лока.
Сейчас хочу второй способ реализовать.

Только моментик подскажи пожалуйста. Я делаю запрос, в котором есть проверка на баланс, гуд. Но уменьшение баланса идет после покупок (занесение данных о покупке в БД). Если запрос не пройдет, это вызовит rollback или лучше сначала делать запрос на уменьшение баланса и только если он прошел успешно - остальные два?

[Валерий Павлов]

Кстати, разве лок мне поможет?
В плане, он же блочит возможность изменений, пока не завершится прошлая транзакция.

Но у меня то получение баланса идет и последующая его проверка.
По сути, ничего не изменится, т.к. получение баланса все еще будет не верным и значения будут браться старые. Разве нет?

[Дмитрий]

Алексей Уколов,

Ну, это, мягко говоря, огромное преувеличение :)

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

З.Ы. Обьективности ради - в такой компании вам выдают функцию в бд getBalance, updateBalance и скажут юзать только их, а за попытку сделать select или упаси боже update вам на всякий пожарный сломают руки. Ибо местному ДБА любопытные люди кажутся страшнее атомной войны

[Дмитрий]

Иван,

В плане, он же блочит возможность изменений, пока не завершится прошлая транзакция.

Нет. Есть shareLock и есть lockForUpdate. И если бы вы сходили по ссылке вы бы прочитали

A shared lock prevents the selected rows from being modified until your transaction is committed:

Alternatively, you may use the lockForUpdate method. A "for update" lock prevents the selected records from being modified or from being selected with another shared lock:

[Дмитрий]

Алексей Уколов, можно. Вы можете сделать локи хоть на все таблицы в бд. Но здесь я вижу один лок- на баланс. Может быть я конечно не понимаю ньюансов. Но пока так.

[Дмитрий]

Иван,

Я делаю запрос, в котором есть проверка на баланс, гуд. Но уменьшение баланса идет после покупок (занесение данных о покупке в БД). Если запрос не пройдет, это вызовит rollback или лучше сначала делать запрос на уменьшение баланса и только если он прошел успешно - остальные два?

В таких ситуациях лучше себя представлять бабкой в МФЦ. Чем раньше вы отправите пользователя нахер за новой справкой - тем вам лучше. И только если уж он пробрался через все тернии, только тогда можете начинать работать.

[Алексей Уколов]

Мягко говоря нет

Преувеличение было не в количестве приложений, а в том, что это уже далеко не «более менее» серьёзная система, а уже очень серьёзная. И там, действительно, всё на уровне БД разруливается :)

Answer 2

[Алексей Уколов]

Нужно просто для всех команд списания с баланса использовать мьютекс, внутри которого:
1. Получать текущий баланс.
2. Проверять, что он больше, либо равен сумме списания.
3. Вносить изменения в БД, если всё ок.
Третий шаг можно реализовать по-разному - через таблицу транзакций, через единственное поле баланса, как у вас сейчас или ещё как угодно. Эта часть совершенно не важна.
Важно только то, что функционал списания с баланса в целом становится однопоточным за счёт блокировки.
Нужно только учитывать, что блокировка должна быть распределённой. Стандартом является использование алгоритма Redlock, реализованном на базе Redis.
Ещё важно использовать один блокировщик именно для всех типов списаний. Если вы в buyProduct будете использовать один мьютекс, а в каком-нибудь buyService другой, то работать это правильно не будет.

Answer 3

[Slava Rozhnev]

В таблице баланса ограничиваете возможность отрицательных значений

create table user_balance (
	user_id int,
  	balance decimal(9, 2) check (balance >=0)
);

create table user_balance_unsigned (
	user_id int,
  	balance decimal(9, 2) unsigned
);

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

SQL online environment

Comments

[Валерий Павлов]

Баланс и так в минус уйти не может, это есть.