Распределённые транзакции: как базы данных избегают потери денег при сбое
Разбираем принцип атомарности распределённых транзакций между несколькими базами данных, протокол двухфазного коммита и его альтернативы для микросервисов.
Ситуация, когда деньги списались с одного счёта, но не поступили на другой из-за сбоя сети между серверами — классическая проблема распределённых систем, для решения которой существуют специальные протоколы координации. Разбираем механизмы, гарантирующие атомарность операций между несколькими базами данных.
Краткий вывод: классический протокол двухфазного коммита гарантирует строгую атомарность, но снижает доступность системы при сбоях; современные микросервисные архитектуры чаще используют паттерн Saga с компенсирующими транзакциями для большей гибкости.
Таблица «На старте»: подходы к распределённым транзакциям
| Подход | Гарантия | Недостаток |
|---|---|---|
| Двухфазный коммит (2PC) | Строгая атомарность всех участников | Блокировка ресурсов при сбое координатора |
| Паттерн Saga | Логическая согласованность через компенсацию | Временное несогласованное состояние возможно |
| Событийная согласованность (eventual consistency) | Согласованность в конечном счёте | Данные временно могут быть неконсистентны |
Проверено по данным каталога СУБД на platforms.su в августе 2026 года.
Почему обычная транзакция не работает между разными базами
Стандартная транзакция ACID эффективна в пределах одной базы данных, но при распределении операции между несколькими независимыми системами нужен дополнительный уровень координации для гарантии одновременного успеха или отката всех частей.
Как работает двухфазный коммит
- Фаза подготовки — координатор запрашивает готовность у всех участников выполнить операцию
- Фаза коммита — при готовности всех участников координатор даёт команду на фактическое применение изменений
- Откат при неготовности — если хотя бы один участник не готов, вся операция отменяется у всех
Когда выбирать паттерн Saga вместо 2PC
Микросервисная архитектура с независимыми базами данных
Для систем, где каждый микросервис управляет собственной базой данных, Saga позволяет избежать жёсткой связанности, характерной для распределённых блокировок 2PC.
Требования к высокой доступности важнее строгой атомарности
Saga продолжает работу при временной недоступности отдельных сервисов через механизм компенсирующих операций, тогда как 2PC блокирует все ресурсы до восстановления координатора.
Чек-лист по выбору механизма распределённых транзакций:
- Оцените критичность строгой атомарности для конкретного бизнес-процесса
- Учтите архитектурные ограничения микросервисной структуры системы
- Спроектируйте компенсирующие операции для каждого шага при выборе Saga
- Протестируйте поведение системы при сбое на промежуточном шаге транзакции
Частые вопросы
Поддерживают ли современные СУБД распределённые транзакции из коробки? Некоторые распределённые СУБД включают встроенную поддержку, но межбазовые транзакции часто требуют реализации на уровне приложения.
Правда ли, что Saga не гарантирует немедленную консистентность? Да, между шагами Saga система может находиться в промежуточном несогласованном состоянии до завершения всей цепочки.
Изучите распределённые СУБД в каталоге СУБД и хранилищ на platforms.su.
Ни один продукт не оплачивал попадание в этот материал. Данные проверены в августе 2026 года.