Если два разных покупателя получили подтверждение покупки последней единицы товара, нужно проверить, как сайт резервирует остаток при одновременных запросах. Простая проверка «товар ещё есть» перед созданием заказа недостаточна: между проверкой и записью другая покупка может занять ту же единицу. Владельцу магазина важно получить воспроизводимый тест и правило, по которому товар достаётся только одному заказу.
Начните с трёх безопасных действий:
- Сверьте у двух заказов точное торговое предложение, склад, время и состояние резерва. Два заказа на разные размеры или склады ещё не доказывают гонку.
- Уточните правило продажи: разрешены ли предзаказ и покупка без наличия, когда товар резервируется и когда резерв освобождается.
- Сохраните обезличенную последовательность событий и передайте её разработчику для проверки на изолированной копии. Не повторяйте покупки с настоящей оплатой ради эксперимента.
Когда два заказа означают ошибку
Гонкой называют ситуацию, когда результат зависит от того, как пересеклись действия нескольких обработчиков. Например, каждый увидел одну свободную единицу, а затем оба разрешили её покупку. При этом в базе может остаться ноль, а не минус: два обработчика способны записать одно и то же вычисленное значение.
Сначала определите, что магазин обещает покупателю. Две предварительные заявки без гарантии наличия допустимы при соответствующих правилах. Два подтверждённых обязательства выдать последнюю единицу требуют разбора. Сообщение в браузере, создание заказа, резерв, оплата и отгрузка — разные события.
Для учебной модели возьмём один склад, один вариант товара, одну единицу и запрет продажи без наличия. До отгрузки правило таково: свободно = физический остаток − действующие резервы; свободно не меньше нуля. Оплаченный, но ещё не отгруженный заказ продолжает занимать товар. После отгрузки физический остаток и резерв изменяются согласованно. В другой учётной модели формула может отличаться — её нужно записать до испытания, исключив двойной вычет одной покупки.
Как воспроизвести конкуренцию на копии
Это учебный протокол для разработчика, а не описание проверки реального магазина. Копия должна использовать ту же версию приложения и настройки резервирования. Подключения к рабочему складу, рассылкам, доставке и платёжному шлюзу отключают либо заменяют тестовыми средами; данные покупателей заменяют искусственными.
- Создайте тестовое предложение на одном складе: физический остаток — одна единица, действующих резервов нет. Убедитесь, что предзаказ запрещён.
- Подготовьте две независимые сессии покупателей А и Б. Каждый оформляет свою покупку с отдельным идентификатором операции.
- Сначала выполните последовательную проверку: А резервирует товар, Б получает понятный отказ по наличию.
- Верните тестовые данные в исходное состояние и запустите оба оформления одновременно. Для устойчивого воспроизведения разработчик синхронизирует старт перед участком резервирования, сохраняя штатные блокировки и проверки.
- Сопоставьте ответы с сохранёнными заказами и резервами. Повторите опыт с другим порядком старта, затем отдельно проверьте отмену и задержанное подтверждение оплаты.
Один удачный проход не доказывает отсутствие гонки. Важна серия повторов с контролируемым пересечением запросов. Если стенд выполняет запросы строго по очереди, он не проверяет нужный сценарий.
Для каждого события нужен компактный журнал: условный покупатель, операция, предложение и склад, переход состояния, количество до и после, результат фиксации. Время получения ответа не всегда показывает порядок записи в базе; нужны сведения о зафиксированных переходах. Секреты, контакты и полные платёжные сообщения в такой отчёт не включают.
Пример ожидаемой последовательности:
- А: резерв подтверждён; свободно 0, зарезервировано 1.
- Б: резерв отклонён; свободно 0, зарезервировано 1.
- А: отмена неоплаченного заказа подтверждена; свободно 1, зарезервировано 0.
- Повтор той же отмены: состояние не меняется.
- Новая покупка Б: резерв подтверждён; свободно 0, зарезервировано 1.
Оплату проверяют отдельной веткой: после подтверждения платежа резерв не должен исчезнуть и снова выставить занятую единицу на продажу.
Какие гипотезы различает журнал
Проверка и резервирование разделены. Оба запроса читают свободный остаток до записи любого из них. Признак — два успешных резерва при исходной одной единице. Нужна проверка границ операции в базе, а не только кнопки в корзине.
Освобождение выполняется повторно. Отмена, истечение срока или повторное уведомление увеличивают свободное количество больше одного раза. Признак — повтор события меняет уже завершённый резерв.
Оплата пересекается с окончанием резерва. Один обработчик подтверждает покупку, другой возвращает товар в продажу. Признак — оплаченный заказ теряет резерв либо та же единица достаётся следующему покупателю. Требуется заранее согласованное правило для поздней оплаты.
Другой канал обходит общий учёт. Сайт, приложение, импорт или ручной заказ считают доступность независимо. Сравните источник каждого изменения и правила распределения товара между каналами. Если расхождение появляется после обмена, полезен отдельный разбор обновления цен и остатков из 1С.
Витрина показывает старое наличие. В карточке доступна покупка, но сервер корректно отклоняет второй резерв. Тогда нужно исправлять показ наличия и сообщение при оформлении. Само устаревшее число на экране ещё не доказывает двойную продажу.
Что должно измениться в резервировании
Проверка достаточного количества и его закрепление за заказом должны образовать неделимую операцию: конкурентный запрос не должен успешно использовать уже занятую единицу. Конкретная реализация зависит от CMS, версии базы и модели складского учёта. Исправление должно охватывать все пути записи, включая фоновые задачи и ручные действия.
Например, документация MySQL 8.0 для InnoDB описывает чтение с блокировкой SELECT... FOR UPDATE. В выбранной реализации разработчик может прочитать нужную строку с такой блокировкой, проверить доступность и согласованно сохранить резерв в одной транзакции на одном соединении. Блокировка удерживается до завершения транзакции; обычного чтения перед последующей записью для такой защиты недостаточно. Это принцип, а не готовый патч для любой CMS.
Транзакцию не следует растягивать на время, пока покупатель вводит платёжные данные. Для ожидания оплаты нужен сохранённый резерв с понятными состояниями. Подтверждение, отмена и истечение срока должны конкурировать по согласованным правилам, а повтор уже обработанного события — оставлять результат прежним.
В документации Stripe отдельно указано, что уведомления могут повторяться и поступать не по порядку. Для своего провайдера нужно проверить его правила; универсального срока ожидания здесь нет. Если оплата подтверждается после освобождения резерва, нельзя молча обещать отгрузку уже занятого товара: требуется предусмотренный процесс сверки и разрешения конфликта.
Не исправляйте проблему массовым обнулением остатков, удалением заказов или автоматическими возвратами. Сначала сохраните историю и разберите подтверждённые обязательства перед покупателями. Эксперименты с отменами и платежами проводят только в тестовой среде.
Защита от повторной отправки одной покупки решает соседнюю задачу. Даже если дубли одной операции исключены, две разные законные покупки всё ещё могут столкнуться за последний товар.
По каким результатам принимать исправление
Попросите протокол с версией изменения, исходными данными, порядком событий и фактическим результатом. Критерии должны проверять состояние данных, а не только отсутствие ошибки на экране:
- При двух конкурентных покупках последней единицы подтверждается один резерв; второй покупатель получает понятный результат без обещания отсутствующего товара.
- После каждой зафиксированной операции соблюдается согласованный баланс. Количество не становится отрицательным и не восстанавливается повторной отменой.
- Сбой между изменением остатка и сохранением резерва не оставляет половину операции. После восстановления можно однозначно установить её результат.
- Отмена, истечение срока и подтверждение оплаты проверены в разном порядке, включая повторы. Поздняя оплата попадает в предусмотренный сценарий.
- Другие предложения и склады продолжают оформляться; обычная покупка без конкуренции работает. Не возникли неприемлемые ожидания из-за слишком широких блокировок.
После выпуска наблюдают нарушения баланса, зависшие резервы, конфликты оплаты и время оформления. Период наблюдения и допустимые задержки согласуют под нагрузку магазина заранее. При откате кода отдельно учитывают новые заказы и резервы: восстановление старой базы может потерять операции, принятые после выпуска.
Что владелец может сделать сам
Без изменения данных можно сверить предложение, склад, статусы и время событий, описать правила продажи и подготовить обезличенный пример. Если штатная команда располагает тестовой копией, понимает учётную модель и может показать протокол, ей достаточно этого задания для самостоятельного разбора.
Помощь нужна, когда резервирование спрятано в чужом модуле, несколько систем меняют остатки или безопасного воспроизведения пока нет. OpenStart занимается доработкой корзины, оформления заказов и интеграций; объём диагностики, стоимость и критерии результата согласуются до начала работ.
Передайте задачу на оценку доработки сайта: опишите симптом, время, версию CMS и обезличенный пример двух покупок. Менеджер уточнит вводные, затем будет согласован первый этап. Пароли, токены и клиентская база для первого обращения не нужны.