Laravel не выдать товар разным пользователям?

Question

[JebKel]

На сайте есть api с помощью которого можно покупать товар, каждый пользователь может одновременно покупать около 200 товаров в секунду и появляется такая проблема, допустим разные пользователи суммарно сделали 1000 запросов за секунду на покупку одного и того же вида товара, как мне выдать каждому уникальный товар? Пытался использовать lockforupdate, но из за него при 200 запросах уже время ожидания было около 10 секунд или более

Comments

[Sanes]

Таблица вроде блокироваться должна при обновлении.

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

Непонятно - у вас количество "товара" ограничено или нет? В чём именно проблема - что не успеваете обрабатывать или что "продаёте" больше, чем есть?

[JebKel]

Алексей Уколов, у меня допустим есть товар, ну игра csgo, я допустим продаю к ней ключи, к api идёт 1000 запросов в секунду на покупку этого товара, как мне быстро выдать заказ, так ещё и уникальный, что бы один и тот же ключ от игры не получили по ошибке другие

[Sanes]

JebKel, коллизии были или вы заранее боитесь?

[JebKel]

Sanes, извиняюсь за вопрос, но что такое коллизии?

[Sanes]

JebKel, это когда уникальность не соблюдается. Один товар в одни руки.

[JebKel]

Sanes, При использовании lockForUpdate нет, товар всегда попадал в одни руки, но с учётом того что при 200 покупок в секунду задержки на получение были около 10 секунд(ожидается более 1000 покупок в секунду). Как я понял lockForUpdate блокирует чтение из за чего и складывается очередь на получение строки и появляется очередь

[Sanes]

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

[Дмитрий]

JebKel, оптимистические блокировки? Skip locked?

Answer 1

[Sanes]

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

Comments

[JebKel]

В этом и проблема, что человек делает запрос на api и в ответе должен получить свой ключ

[Sanes]

JebKel, при каком условии он его должен получить?

[JebKel]

1 - хватает баланса, 2 - есть в наличии, больше условий и нет на получение

[Sanes]

JebKel, через заказ и делайте.

1. запрос на ключ - ответ № заказа или нет в наличии/недостаточно средств
   
2. запрос заказа - ответ статус или ключ
   

[JebKel]

Sanes, Заказчику нужно сделать что бы api был такой же как и у конкурентов, а у них просто запрос -> ключ

[Sanes]

JebKel, я бы так сделал. Это гарантированная схема.

[Sanes]

если там реально столько запросов. В чем я сильно сомневаюсь. С таким трафиком у вас бюджеты должны быть миллионные.

[JebKel]

Ну почему же, не миллионные конечно, просто каждый пользователь может покупать N кол-во ключей в секунду, ну к примеру 200, но это только 1 пользователь, а таких пользователей много

[Sanes]

JebKel, прям каждую секунду? Проверяли?

[Sanes]

JebKel, ну давайте посчитаем.
Прибыль с одного ключа 1₽.
3 600 000₽ в час.
Я рад за вас.

[JebKel]

да, в данный момент есть проект в продакшене, который не справляется вообще с нагрузкой, там стоит ограничение на 350 запросов в секунду, много пользователей потеряли из за того, что с нагрузкой не справляется вовсе

[JebKel]

Sanes, ну тут появляется фактор что не все ключи работают и за ну 30-50% заказов идёт возврат, ключи я просто аналогию привёл

[Sanes]

JebKel, делайте по-своему. Можете с транзакциями пострадать.