Компенсационные транзакции: как откатить хаос и не потерять данные
Представьте ситуацию: пользователь покупает «Тур под ключ», но на этапе оплаты его карта отклонена. Авиабилет и отель уже забронированы. Ваша система должна отменить все эти изменения, не оставив недовольных клиентов. Классические транзакции тут не работают. Выход — компенсационные транзакции. Давайте разберем, как это работает и когда это нужно и можно применять.
🔄 Что такое компенсационные транзакции
В распределенных системах отмена изменений, которые уже произошли в нескольких участниках взаимодействия, — одна из главных проблем. Компенсационные транзакции — это механизм отката таких изменений. Для отмены операции выполняются специальные действия, которые отменяют уже произошедшие операции у всех затронутых участниках.
📌 Пример: Отмена заказа в интернет-магазине: если что-то пошло не так, система возвращает деньги и снимает бронь с заказа, вместо того чтобы «заморозить» все до завершения процесса.
Компенсационные транзакции являются ключевым элементом паттерна SAGA. В SAGA сложный бизнес-процесс разбивается на последовательные шаги. Для каждого шага заранее определяется «обратная» операция. Если что-то пошло не так, то, в зависимости от реализации, либо оркестратор вызывает обратные операции, либо, в случае хореографии, сами участники реагируют на сообщения отмены операции и производят действия для отката.
✈ Пример с туром: Рассмотрим в качестве примера компенсационных транзакций бронирование тура:
- Бронирование авиабилета — ✅ успешно.
- Бронирование отеля — ✅ успешно.
- Оплата тура — ❌ ошибка.
🔄 Запускаются компенсационные действия со стороны SAGA-оркестратора:
- ❎ Отмена бронирования отеля
- ❎ Отмена бронирования авиабилета
Система возвращается в исходное состояние, как будто бронирования и не было.
🛠 В каких системах их лучше всего использовать
Подход с компенсационными транзакциями эффективен для систем со следующими характеристиками:
- Распределенные системы и/или микросервисная архитектура с большим числом интеграций и большим числом участников в бизнес-процессах.
- Высокие требования к доступности — недопустимы долгие блокировки ресурсов, как в двухфазных комитах.
- Длительные бизнес-транзакции — процессы занимают длительное время или требуют ручного подтверждения.
- Приемлема конечная согласованность данных (eventual consistency) — мы осознаем, что в некоторые моменты времени данные в системе будут не согласованы между собой.
🏗Инфраструктура
Для того чтобы эффективно использовать подход компенсационных транзакций, ваша инфраструктура должна включать:
- Надежную систему обмена сообщениями — очереди или брокеры сообщений, которые будут гарантировать доставку сообщений даже в случае недоступности сервисов.
- Механизмы оркестрации/хореографии и мониторинга — в системе может быть явный оркестратор или обмен событиями будет реализован через хореографию. А хороший мониторинг обеспечит быстрый поиск того, что пошло не так.
- Идемпотентность операций — события могут приходить повторно, поэтому участники взаимодействия должны обрабатывать операции повторно без отрицательных последствий.
🚫 Когда не стоит использовать компенсационные транзакции
Как и любой архитектурный паттерн, компенсационные транзакции имеют свои ограничения. Хорошо подумайте, стоит ли использовать, когда:
- Требуется строгая согласованность данных — в некоторых случаях конечная согласованность недопустима, например сделки с ценными бумагами в реальном времени.
- Бизнес-процессы необратимы и компенсация возможна только путем нового действия. Например, товар уже загрузили и отправили или чек напечатали, в этом случае нам нужно использовать новый бизнес-процесс для отмены предыдущего.
- Системы с нулевой терпимостью к ошибкам — авионика, энергетика и т. п.
- Инфраструктура не готова — нет очередей, нет идемпотентности и гарантии повторяемости операций, нет механизма устойчивого хранения состояния.
✅ Заключение
Компенсационные транзакции — это отличный подход для реализации конечной согласованности (eventual consistency) в распределенных системах. Они идеально подходят для высокодоступных систем со слабой связанностью. Но использование этого подхода требует наличия подходящей инфраструктуры. Они точно не подходят для систем реального времени и там, где нужна строгая согласованность данных.
👉 Стоит выбирать компенсационные транзакции, когда их преимущества перевешивают сложности реализации.
Подписывайся на мой канал в telegram