ACID транзакции мощный инструмент, которые позволяет поддерживать целостность данных в реляционных СУБД. Это очень простой в использовании механизм - если что-то пошло не так, то мы откатываем транзакцию, а данные остаются согласованными.
В микросервисной архитектуре каждый сервис владеет своими данными и (в идеале) своей выделенной БД. Да, в микросервисной архитектуре возможно реализовать механизм ACID транзакций, например через протокол 2 phase commit, но это будет нарушать ключевые принципы микросервисов - независимость, масштабируемость и отказоустойчивость.
Если привести наглядный пример, то вы не можете "заблокировать" данные в сервисе "Заказ", "Доставка" одновременно с сервисом "Платежи" и потом одновременно подтвердить или отклонить изменения из всех сервисов. Это технически реализуемо, но ценой больших сложностей и проблем.
Почему использование 2PC - это плохой выбор
Подход двухфазного комита (2PC) - классическое решение для распределенных транзакций. Но использование его в микросервисной архитектуре не стоит по следующим причинам:
- Блокировки и снижение доступности - 2PC блокирует ресурсы на время выполнения всего процесса, а это убивает производительность и делает всю систему уязвимой к сбоям.
- Высокая связанность (High Coupling) - все участники системы должны быть готовы к взаимодействию с координатором транзакции. Это превращает микросервисную систему в распределенный монолит.
- Сложность внедрения и поддержки - 2PC вносит дополнительную сложность в реализацию инраструтурного слоя.
2PC сводит на нет все преимущества микросервисной архитектуры и превращает систему в распределенный монолит.
Компенсационные транзакции: бизнес-логика вместо технического rollback
В отличие от технического отката, который стирает изменения, подход с компенсационными транзакциями - это новый бизнес-процесс, который отменяет предыдущие действия.
Этот подход лежит в основе паттерна Saga. Saga - разбивает глобальный процесс на последовательность локальных транзакций и для каждого шага определяет свою компенсирующую операцию. Если один из шагов падает, Saga запускает компенсации в обратном порядке.
Важно понять, что компенсации - это не "аварийный план", а естественная часть бизнес-процесса и они должны проектироваться вместе с основными действиями.
Ключевое преимущество - компенсационные транзакции сохраняют автономность сервисов. Каждый из них отвечает только за свои данные, не зная о внутреннем устройстве соседних сервисов.
Компенсации не заменяют ACID, они меняют сам подход — с технической целостности на бизнес-согласованность.
А вы пробовали использовать 2PC в распределенных системах?
Переходи в мой телеграм-канал по ссылке
#SoftwareArchitecture #saga #transactions #eventdriven #microservices #acid #2pc