Шаблон саги позволяет вам координировать ряд операций, а в случае сбоя одного из шагов, он позволяет вам координировать шаги, чтобы отменить то, что было сделано до сих пор, так что вы можете увидеть это в способ сделать все шаги transactional без фактической транзакции.
Но саги не могут изменить природу каждого из шагов, которые вы делаете. Зарядка клиента - это операция, которую мы можем отменить, потому что мы можем создать компенсационное действие, например, вернуть средства клиенту. Выплата денег клиенту - это операция, которую мы не можем отменить, потому что, как только деньги окажутся в руках клиента, мы не сможем их вернуть. Поэтому сага может помочь вам удостовериться, что все шаги выполнены, или убедиться, что ничего не произошло, но не позволит вам обратить вспять вещи, которые нельзя повернуть вспять.
В этом случае вы можете оставить операцию, которая не может быть отменена до конца. Например, обесцените деньги из кошелька клиента (который является операцией в вашей базе данных), а затем выполните фактическую выплату. Если выплата не удалась, сага позволит вам отменить вычитание из кошелька клиента, поэтому никакого «ущерба» не будет.
Обновление : дополнительная информация добавляется на основе на комментарий
Саги (обычно) реализованы с помощью обмена сообщениями. Сага - это оркестровщик, она на самом деле не выполняет реальных шагов. Вместо этого он отправляет команды, так что другие процессы выполняют шаги и получает сообщения или события с результатами операций.
Также обратите внимание, что шаги, выполняемые сагой, могут иметь временные сбои или неисправимые / постоянные сбои. Временные сбои могут быть повторены, и, скорее всего, они будут успешными. Постоянные сбои не удастся повторить.
Учитывая все это, я решил бы эту проблему следующим образом:
- Отправьте команду на обновление БД и сохраните информацию о том, что транзакция происходит. Это блокирует средства, поэтому, даже если выплата еще не произошла, вы не можете инициировать еще одну и в итоге выплачивать слишком много денег. Сбои здесь могут быть временными (дБ недоступны) или постоянными (недостаточно средств). Вы можете повторить временные сбои до тех пор, пока они не сработают, и уведомить о постоянных сбоях. Отправьте сообщение обратно в сагу с результатом операции.
- Если шаг 1 выполнен успешно, отправьте команду для выполнения выплаты. Временный сбой: внешний сервис недоступен. Повторите попытку до X раз. Постоянный: данные о выплатах недействительны. Если выплата не может произойти, сага компенсирует шаг 1 и высвободит средства в кошельке. Отправьте сообщение обратно в сагу с результатом: либо сбой, либо ответ от внешней службы HTTP.
- Если выплата не удалась, отправьте команду для отката, шаг 1. Если все прошло успешно, отправьте команду на подтвердите выплату и сохраните ответ в БД. Обратите внимание, что здесь не должно быть постоянных сбоев при обновлении БД. Самое большее, у вас могут быть временные сбои (база данных недоступна), но повторная попытка должна привести к окончательному обновлению БД. Если даже после многих попыток операция не может быть успешной. Вам потребуется ручное вмешательство и устранение проблемы, поскольку вы не можете откатить шаг 2. Вы должны смоделировать процесс так, чтобы этот шаг был надежным (проверки и другие вещи, которые могут вызвать постоянные сбои, должны быть обнаружены на шаге 1 или 2) .
Надеюсь, это имеет смысл. Вы должны убедиться, что вы охватили все сценарии ios и что вы можете отправлять сообщения надежно, даже если операция не удалась.