Контроль одновременных платежей - PullRequest
1 голос
/ 27 октября 2019

Когда я нажимаю «Разместить заказ», я начинаю транзакцию и устанавливаю для столбца is_payment_processing значение True, прежде чем перевести пользователя на веб-сайт продавца, и тогда возможны три варианта:

  1. Пользователь приземлился на странице обратного вызова при успешном выполнении
  2. Пользователь приземлился на странице обратного вызова при сбое
  3. Пользователь не попал ни в случае успешного завершения, ни при сбое обратного вызова, потому что он закрыл окно.

В третьем сценарии: продукт останется в состоянии, в котором is_payment_processing равно True. И другие пользователи, которые пытаются проверить тот же продукт, не смогут это сделать. Но в этом случае я могу потерять некоторых клиентов и причинить некоторые неудобства.

Подумайте, что каждую минуту нужно запускать задание cron, которое будет отслеживать время последнего изменения этого столбца и, если оно не былоизменен более чем на 3 минуты, затем установите этот флаг в False.

Какой подход должен быть лучшим здесь? Как в общем сценарии это реализовано? (Контроль параллелизма)

Другая мысль в мыслях: Посетите этот вопрос

Ответы [ 2 ]

0 голосов
/ 27 октября 2019

Cron кажется наилучшим подходом, если вы можете (если вы находитесь на общем хосте, многие провайдеры не разрешают вам использовать какие-либо кроны)все еще в процессе. (Здесь я предполагаю, что у меня есть механизм для этого)

РЕДАКТИРОВАТЬ: обратите внимание, блокировка инвентаря, когда транзакция платежа выполняется, довольно стандартная

0 голосов
/ 27 октября 2019

В идеале у вас должно быть поле stock в вашей модели Product, чтобы сохранить количество доступных количеств для этого продукта.

Когда кто-то размещает заказ, должен быть создан отдельный экземпляр orderс указанным количеством Prodduct. Запас должен быть уменьшен только после получения обратного вызова для этого order или получения веб-крюка, подтверждающего оплату.

Это не помешает другим клиентам размещать заказы на тот же продукт до тех пор, пока товар фактически не будетпродано.

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

Примечание: использовать F объект из django.models при сокращении запаса, чтобы уменьшить запас из значения БД, а не атрибута экземпляра.

...