Блог

У меня есть клиентское приложение, которое добавляет товары в корзину. Операция «добавить» запускает запрос на обновление через HTTP-вызов REST на удаленную конечную точку. Пожалуйста, обратите внимание: этот запрос содержит всю корзину в целом, а не только добавляемый товар. Затем этот запрос распределяется между двумя серверами с использованием алгоритма циклического перебора.

Проблема, которую я пытаюсь решить, заключается в том, что клиент не ожидает возврата запроса «добавить», прежде чем запускать другой запрос «добавить», если пользователь это сделает. Это хорошо с точки зрения конечного пользователя, потому что пользователю не нужно ждать. Но это кошмар с точки зрения сервера: вы не можете быть уверены, в каком порядке запросы будут обрабатываться из-за балансировщика нагрузки.

Вот пример:

• Пользователь добавляет товар № 1 в корзину. Отправляется запрос A.
• Пользователь добавляет товар № 2 в корзину. Отправляется запрос B. Пожалуйста, обратите внимание, что запрос B отправляется до того, как запрос A получил ответ.
• Запрос A сбалансирован по нагрузке на сервере 1, а запрос B сбалансирован по нагрузке на сервере 2
• По некоторым причинам сервер 1 работает медленнее, чем сервер 2, поэтому запрос B обрабатывается первым => в корзине есть товары № 1 и № 2
• Сервер 1 обрабатывает запрос A => в корзине есть только товар № 1 (напоминание: каждый запрос на обновление содержит корзину wole)

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

• Отправьте временную метку с запросом и сохраните временную метку в базе данных. Перед обновлением корзины убедитесь, что временная метка запроса выше. В противном случае отбросьте запрос. Но это в значительной степени зависит от поведения на стороне клиента.
• Установите номер версии в самой корзине и увеличивайте его при каждом обновлении. Это заставило бы клиента ждать ответа, прежде чем отправлять другое обновление. Не очень удовлетворительно с точки зрения конечного пользователя, потому что ему приходится ждать.
• Установите «привязку сеанса» к балансировщику нагрузки, чтобы запросы от конкретного клиента каждый раз отправлялись на один и тот же сервер. Проблема в том, что это влияет на баланс нагрузки на сервер.

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

Самым простым способом было бы отправить детали операции (добавлено # 1, добавлено # 2 …), Чтобы иметь возможность поэтапно восстанавливать корзину на серверах. С этой информацией вы вообще не полагаетесь на запросы, обрабатываемые в определенном порядке.

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