Распределённые транзакции становятся болезненными там, где бизнес требует атомарности, а архитектура уже разделена на несколько сервисов и хранилищ.
В реальной инженерной работе эта глава помогает выбирать между двухфазной фиксацией, трёхфазной фиксацией, Saga и транзакционным журналом исходящих событий по границам домена, допустимым сбоям, блокировкам и цене координации.
В интервью и архитектурных разговорах она особенно полезна, когда нужно честно проговорить семантику тайм-аутов, частичную фиксацию, компенсации и требования к идемпотентности.
Практическая польза главы
Практика проектирования
Учит выбирать транзакционный паттерн по границам домена и допустимым сбоям.
Качество решений
Помогает сравнить двухфазную фиксацию, трёхфазную фиксацию и Saga через задержку, блокировки и операционную сложность.
Аргументация на интервью
Дает ясную схему объяснения координатора, участников, точки фиксации и пути восстановления.
Риски и компромиссы
Делает явными блокировки, частичную фиксацию, семантику тайм-аутов и требования к идемпотентности.
Контекст
Консистентность и идемпотентность
Распределённые транзакции — один из способов удержать согласованность, но не единственный.
нужна, когда важнее автономности отдельных сервисов. В таких сценариях важны , , , , и .
Перед выбором важно отделить от : это между атомарностью, доступностью и эксплуатационной ценой. На границах сервисов рядом часто появляется , чтобы сбой одного участника не забрал всю систему.
Цена проявляется при , , и . Поэтому рядом с протоколами фиксации часто проектируют , , , , , , и обработку .
Распределённые транзакции: 2PC и 3PC нужны, когда бизнес-инвариант требует согласованного изменения нескольких независимых ресурсов. Цена такого выбора — задержки, блокировки и сложное восстановление после частичных отказов.
Когда нужна распределённая транзакция
- Одна бизнес-операция должна атомарно изменить несколько независимых ресурсов или сервисов.
- Для этого класса операций нельзя допустить даже временное расхождение состояния.
- Частичная фиксация грозит финансовыми, регуляторными или пользовательскими последствиями.
Как работает двухфазная фиксация (2PC)
2PC: двухфазная фиксация
Prepare -> голоса участников -> общее решение COMMIT/ABORT
Координатор собирает голоса участников и принимает единое решение: зафиксировать или отменить всю транзакцию.
Сильные стороны
- Простая и понятная модель координации.
- Чётко отделяет фазу подготовки от финального решения.
Риски
- Блокировки при отказе координатора в неподходящий момент.
- Высокая чувствительность к настройкам тайм-аутов и повторов.
Шаги протокола
Текущая команда
Нажмите Старт, чтобы проиграть протокол по шагам.
Координатор
Ожидает запуск
Команд от координатора: 0
Участники
3 участника
Шаг: 0 / 8
Заказы
участник A
Ожидание команд
Участвовал в шагах: 0
Платежи
участник B
Ожидание команд
Участвовал в шагах: 0
Склад
участник C
Ожидание команд
Участвовал в шагах: 0
Как работает трёхфазная фиксация (3PC)
3PC: трёхфазная фиксация
CanCommit -> PreCommit -> DoCommit
Добавляет промежуточную фазу PreCommit, чтобы уменьшить риск блокировок при проблемах координатора.
Сильные стороны
- Снижает вероятность зависания в неопределённом состоянии.
- Явно разделяет намерение зафиксировать изменения и финальную команду.
Риски
- Больше сетевых раундов и более сложный конечный автомат.
- Требует очень аккуратной настройки тайм-аутов и восстановления.
Шаги протокола
Текущая команда
Нажмите Старт, чтобы проиграть протокол по шагам.
Координатор
Ожидает запуск
Команд от координатора: 0
Участники
3 участника
Шаг: 0 / 12
Заказы
участник A
Ожидание команд
Участвовал в шагах: 0
Платежи
участник B
Ожидание команд
Участвовал в шагах: 0
Склад
участник C
Ожидание команд
Участвовал в шагах: 0
Альтернатива
Event-Driven Architecture
Во многих сценариях Saga и транзакционный журнал исходящих событий дают лучший баланс, чем глобальная фиксация.
Компромиссы и альтернативы
Двухфазную фиксацию проще объяснить и внедрить, но она может заблокировать участников, если координатор отказал после подготовки.
Трёхфазная фиксация снижает риск зависания, но добавляет сетевой раунд и усложняет конечный автомат протокола.
Оба подхода чувствительны к сетевым разделениям, тайм-аутам и корректному восстановлению после частичных сбоев.
В микросервисной архитектуре общая атомарная транзакция между сервисами часто оказывается слишком дорогой и хрупкой.
Saga: оркестрация или хореография
Разбивает операцию на локальные шаги и компенсирующие действия вместо глобальной синхронной фиксации.
Транзакционный журнал исходящих событий
Записывает событие рядом с бизнес-изменением в локальной БД, а публикует его позже безопасным воркером.
Идемпотентные команды и согласование состояния
Безопасные повторы и фоновая сверка уменьшают последствия частичных сбоев.
Пересмотр границ домена
Иногда дешевле изменить границы агрегатов и убрать требование атомарности между сервисами.
Практический чеклист
- Явно определено, где нужна атомарность, а где допустима согласованность в конечном итоге.
- У координатора есть стратегия восстановления и долговечный журнал транзакции.
- Политики тайм-аутов проверены на сетевых разделениях и задержках.
- Все участники безопасно обрабатывают повторные команды COMMIT и ABORT.
- Есть бизнес-механизм компенсации и ручного разрешения спорных случаев.
Частая ошибка: вводить двухфазную фиксацию между сервисами без оценки блокировок, модели повторов и стоимости восстановления.
Источники
Связанные главы
- Консистентность и идемпотентность - Идемпотентность нужна, чтобы безопасно обрабатывать повторы и восстановление после сбоев.
- Event-Driven Architecture - Saga и асинхронная координация как практичная альтернатива общей XA-транзакции.
- Паттерны отказоустойчивости - Тайм-ауты, повторы и изоляция по отсекам определяют поведение транзакции при сбоях.
- Выбор лидера: паттерны и реализации - Паттерн координатора часто опирается на лидерскую координацию.
- Тестирование распределённых систем - Проверяйте частичную фиксацию, тайм-ауты и восстановление до запуска в рабочей среде.