Обработка с параллельными дублирующимися запросами

Question

У меня есть конечная точка REST, которая называется CancelOrder.Он состоит из четырех шагов (по порядку):

1. Отмена выполнения (Вызывает нисходящую услугу).
2. Отмена предложения (Вызывает нисходящую услугу).
3. Обновлениесостояние заказа cancelled (в нашей локальной базе данных).

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

Сценарий 1:

1. Всего один вызов :

   Отмена выполнения, отмена предложения, обновление состояния.Все хорошо.

2. Вызов находится на полпути, когда получен другой вызов.Предположим, что пессимистическая блокировка отсутствует :

   Состояние заказа еще не было изменено на «отменено» предыдущим вызовом, но выполнение было отменено.Теперь, когда второй вызов попытался отменить выполнение, он возвращает ошибку.

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

Как мне справиться с этим сценарием?

Answer 1

Существует 2 способа (среди множества других решений) справиться с этим сценарием:

Решение A:

1. Добавить новое состояние в порядке как isCanceling.После получения сервером первого запроса на отмену заказа установите это состояние как true.После завершения операции отмены установите это состояние как false.
2. Если сервер получит еще один запрос на отмену по тому же заказу, но обнаружит, что его статус равен isCanceling, сервер вернет клиенту 102 Processing,указывает на то, что операция выполняется.

Решение B:

1. аналогично шагу 1 в решении A.
2. Каждый раз, когда сервер получает запрос на отмену(включая первый), в очередь этого заказа добавляется прослушиватель, ожидающий уведомления о событиях «Отмена-ОК» или «Отмена-отказ».
3. Если сервер получает запрос на отмену заказа, нообнаружив, что он имеет статус isCanceling, сервер ничего не будет делать, кроме как просто добавит соответствующий прослушиватель в вышеуказанную очередь.
4. После завершения операции отмены (успех или неудача) происходит событие.Все слушатели в очереди получат сообщение, и ответ HTTP будет возвращен для всех предыдущих ожидающих запросов HTTP.

Лично я предпочитаю Решение B.