Как компенсировать задержку?

Question

[Sergo Sergo]

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

Comments

[Silm]

Любопытно. Сколько покупок в секунду?

[Sergo Sergo]

Silm: когда магазин пополняется, все скупается моментально

[Silm]

Sergo Sergo: до сих пор любопытно, сколько получается покупок в секунду?

Answer 1

[Виталий Кравчишин]

Почитайте: транзакции и блокировки

Answer 2

[Максим Тимофеев]

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

Comments

[Niomin]

С одной стороны, это неплохо: пользователю не дадут купить что-либо, если это хочет купить другой человек.
Но что делать, если кто-то об этом узнает, и будет собирать в корзину весь магазин? Вводить капчу на каждой странице — не очень здорово.

[Максим Тимофеев]

Niomin: 1. Кому это надо? 2. Как узнают? 3. Как по другому? 4. Держите бронь для товаров с маленьким остатком малое кол-во времени. Либо перед оплатой уже бронируйте.

[Niomin]

Максим Тимофеев: 1. Кхм. То есть оставлять потенциальную уязвимость только из-за того, что сегодня ей никто не хочет воспользоваться? :) Если вы считаете, что в вашем проекте база пользователей никому не нужна, то можно хранить её дамп в корне, в файле dump.sql, открытом для чтения снаружи? :)
2. Да как угодно.
3. См. два ответа выше
4. Принципиально не решит проблему. Можно это делать часто, если возникнет желание :)
То есть понятно, что так в целом можно сделать, с другой стороны — если товары быстро раскупают, то почему бы не отдать предпочтение тем, кто быстрее заплатит?

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

[Dimonchik]

Максим Тимофеев: узнАют так, что это давно уже проблема для больших магазов типа Мвидео, и не только, вплоть до того, что тут обсуждалось. Парсеры на месте не стоят

[Roman K]

Максим Тимофеев: Так вот после кого я дырки в сайтах нахожу)

[mitaichik]

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

[Dimonchik]

mitaichik: решают в офлайн логистическом слое, если кратко - резервирование на складе / у поставщика после подтверждения заказа по телефону. Проблема невыкупа заказов тоже ведь есть, 20% в среднем (не знаю, сколько на больших оборотах, ну и на маленьких, наверно, все 50). А в корзинах обычно товар висит до посинения - если чел залогинившийся или слепой логин - до момента checkout товар есть 100%, предрезервирование на складе - после checkout (тут парсеры уже 100500 работающих телефонов не впишут), ну и дальше логистика со всеми ее "а мне из другого уже привезли раньше" прелестями

Answer 3

[Niomin]

В момент покупки товара использовать транзакцию и запрос вида select for update
Подробно расписано в документации

Answer 4

[Илья Воропаев]

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