Как в ларавель 5.5 заставить mysql обрабатывать запросы по очереди?

Question

[JaguXam]

Проблема в следующем.

На сайте могут быть 2-3 запроса в секунду от одного пользователя.
В базе есть баланс, когда он нажимает одновременно с милисекундой на кнопку заплатить, списывается только 1 раз, так-как сайт или база не успевают обработать этот запрос, он идет одновременно.

На даннай момент я делаю так, строго не судите это мой первый опыт работы с балансом.
$this->user->money - $amount
$this->user->save();

Можно как-то заставить сайт обрабатывать запросы на изменение балансов по очереди ?
Заранее спасибо за ответ.

Comments

[Adamos]

Если пользователь нажимает "заплатить" три раза в секунду - скорее всего, у него просто проблема с мышкой...

[Иван Шумов]

Adamos, это не означает что он должен страдать

Answer 1

[Иван Шумов]

И решается это ... барабанная дробь ... очередями! Rabbitmq, Kafka и другими вариантами. Кстати, Хранить баланс прямо в пользователе - плохая идея.

А если хорошо подумать то надо читать про идемпотентные операции и не снимать деньги со счета, а создавать изначально транзакцию и ее закрывать, Ама фоне, асинхронно, пересчитывать баланс

Comments

[JaguXam]

Большое спасибо.
С очередями понял, а вот по тому что ниже ... Я еще не готов, но буду разбираться)

[Иван Шумов]

JaguXam, это будет следующим шагом в осознании асинхронных систем по тому что очереди синхронными не бывают)

[Alex Wells]

Какие нахрен очереди? Издеваетесь что ли? На каждый чих по джобе?

Читайте мой ответ, ТС. Это НЕ ответ.

[Иван Шумов]

Alex Wells, это финансовые операции. Тут надо так. Это референсная архитектура в данном домене

[Alex Wells]

Иван Шумов, это не финансовые операции, вообще. Это баланс на левом сайте.

А даже если бы были финансовые операции, что тогда? У нас на проекте миллионы транзакций обрабатываются, локи справляются просто прекрасно.

[Иван Шумов]

Alex Wells, я вам сочувствую. Делали, страдали, не надо так

[Alex Wells]

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

[vism]

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

Answer 2

[Alex Wells]

Открываете транзакцию, вытаскиваете юзера с локом ->lockForUpdate(), проводите свои манипуляции/проверки, сейвите, комиттите транзакцию.

DB::transaction(function () use (&$user) {
    $user = User::whereKey($user->getKey())->lockForUpdate()->firstOrFail();
    if ($user->balance) // blabla
    $user->balance -= 100;
    $user->save();
});

Ничего более не нужно.

Comments

[Иван Шумов]

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

[Alex Wells]

Иван Шумов, подряд может, но багов с проверками на баланс уже не будет. Если у него на балансе 100, то списать 100 он сможет только единожды, как бы он не извращался.

[Alex Wells]

А проблему с "подряд" уже да, можно решать отдельными сущностями. Так или иначе, это всегда нужно делать с локами.

[Иван Шумов]

Alex Wells, если у него тысяча то он сможет списать 10 раз. В этом и проблема у ТС, поэтому данное решение, мягко говоря, отправляется в мусорное ведро

[Alex Wells]

Иван Шумов, что? Где проблема то? У ТС проблема, что юзер получает товар три раза, а списываются деньги - единожды. Это решается локами и ТОЛЬКО ими. Очереди тут не помогут никак, только если и логика покупки товара будет в очереди, а это полный идиотизм.

Единственное решение, которое отправляется в мусорное ведро, это твое. Как минимум потому что оно не работает. Как максимум потому что это хуевое решение.