последний товар в корзине - PullRequest
       19

последний товар в корзине

0 голосов
/ 01 сентября 2018

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

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

Несколько решений, которые приходят мне в голову, похожи на:

  1. Примите оплату с обоих счетов и позднее отмените транзакцию для одного из них, который оплатил позже первого. Это не будет хорошей практикой, поскольку это приведет к улучшению качества обслуживания клиентов.
  2. Оставьте в запасе несколько предметов и используйте их в случае перебронирования.
  3. Я забыл, что делает Amazon, и на каждом этапе заказа осуществляю проверку количества в сервисе заказа из сервиса Item через вызовы REST. Но эти проверки иногда могут потерпеть неудачу, когда много людей заказывают один и тот же товар. например, во флэш-продажах

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

Ответы [ 2 ]

0 голосов
/ 01 сентября 2018

Я не могу ответить, как это делает Амаозон, и я не думаю, что кто-то мог бы на публичном форуме, я могу рассказать вам, как, по моему мнению, это можно сделать. Таким образом, вы должны заблокировать свой инвентарь, если хотите убедиться, что вы точно сопоставили инвентарь с заказом. Если вы собираетесь это сделать, вопрос будет в том, где вы берете блокировку. Когда товар добавляется в корзину, когда пользователь идет на оплату или когда платеж сделан. Но проблема с блокировкой в ​​том, что она замедлит работу системы. Так что это то, что вы должны избегать.

Остальные варианты, которые вы уже рассмотрели в своем вопросе, сводятся к компромиссам.

Во-первых, пользовательский опыт пострадает, и вам также придется понести стоимость транзакции.

Второй вариант - попросить вас быть готовым перепродать или перепродать. Когда вы держите резервы, вы в основном говорите, что я буду продавать меньше. Это также может иметь неприятные последствия, потому что, скажем, вы решили зарезервировать 5 предметов, но вы получите 20 одновременных запросов на оплату заказа и оплату, вы вернетесь к исходной точке. Но это может помочь в большинстве сценариев, если вы готовы принять удар.

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

Итак, что я делаю в таких сценариях, так это 1. Мой инвентарь идет не как число, а как перечисление, т.е. критическое, низкое, среднее, высокое, очень высокое В зависимости от аналитики мы настраиваем проверку запасов. Для высокого и очень высокого уровня мы не будем проверять и бронировать товар. для критических и мы берем замок. (не совсем блокировка дб, но мы оставляем за собой инвентарь для них), для низкого и среднего уровня мы проверяем инвентарь и действуем, если нам достаточно. Все эти значения настраиваются и помогают нам смягчить сценарии, которые у нас есть.

Еще одна вещь, которую мы пытаемся - это распределить инвентарь среди брокеров инвентаризации и назначить брокера инвентаризации какому-то набору услуг для просмотра этого инвентаря. Даже если мы зарезервируем инвентарь у одного брокера, другие могут продолжать свободно продавать. И там брокеры регулярно обновляют инвентаризацию мастера о состоянии инвентаря. Как и в Inventory Master, у него 50 предметов, каждый из которых распределяется по 5. Через 10 минут они возвращаются и, если им нужно больше инвентаря, они просят его, если они остались (в случае неудачи), они возвращают инвентарь мастеру, чтобы он был назначен другим.

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

0 голосов
/ 01 сентября 2018

Подумайте о том, чтобы:

  1. На странице оплаты необходимо повторно проверить, доступен ли продукт. Это может быть простой HTTP GET.

  2. Если вызов GET медленный для вас, рассмотрите возможность кэширования недавнего продукта, добавленного пользователем, в некоторые базы данных в памяти (например, REDIS). Теперь, если первые пользователи успешно обработали платеж, уменьшите счетчик для этого идентификатора продукта в redis. И прежде чем продолжить оплату за второго пользователя, проверьте счетчик этого идентификатора продукта в redis.

(БОНУС: Redis предлагает атомарные операции, так что вы можете успешно справиться с состоянием гонки при заказе продукта).

...