Three-Phase Commit (3PC)

Mental model: 3PC = 2PC + промежуточная фаза PreCommit, которая ломает блокирующее ожидание участников при падении координатора. Если все участники получили PreCommit — каждый знает, что все остальные тоже проголосовали YES, и любой выживший может безопасно завершить транзакцию commit-ом без координатора. Цена: лишний round-trip. Условие: synchronous network, no partitions. В реальной асинхронной сети 3PC ломается ровно так же, как любой алгоритм без consensus.

Зачем

2PC имеет одну неизлечимую болезнь — blocking problem. Участник проголосовал YES, записал prepared-запись в WAL, удержал locks — и теперь обязан ждать решения координатора. Если координатор упал между Phase 1 (vote) и Phase 2 (decision), участник застрял: ни commit, ни abort самостоятельно сделать нельзя. Locks держатся, очереди читателей растут, downstream сервисы тайм-аутят, метрики краснеют. Восстановление = ручной DBA с pg_xact_status или ждать возврата координатора (single point of blocking).

3PC проектировался как академический ответ на эту проблему. Skeen (1982) предложил вставить между vote и decision дополнительную фазу PreCommit. Ключевой инвариант: если участник перешёл в PRE-COMMIT state, значит все участники проголосовали YES, и все участники тоже либо уже в PRE-COMMIT, либо туда дойдут. Это значит: при падении координатора выжившие участники могут договориться между собой и завершить транзакцию без блокирования.

Звучит красиво. Не используется почти нигде. Почему — см. ADR-002 и сценарий partition-breaks-3pc.

Mental model

Phase 1: CanCommit?    -> голосование (как в 2PC)
Phase 2: PreCommit     -> "все voted YES, готовьтесь" (новая фаза)
Phase 3: DoCommit      -> "commit прямо сейчас" (как Phase 2 в 2PC)

Каждая фаза = round-trip coord <-> participants. 2PC = 2 round-trip-а, 3PC = 3. На LAN с 1ms ping-ом разница смешная (3ms vs 2ms), на cross-region с 80ms ping-ом — 240ms vs 160ms на каждую транзакцию.

Инвариант, ради которого всё затеяно: между концом Phase 2 и началом Phase 3 любой участник знает, что транзакция точно будет committed. Поэтому если в этом промежутке координатор умер, выживший участник может: (a) дождаться timeout, (b) elect new coordinator, (c) опросить других, (d) если кто-то в PRE-COMMIT — все коммитят, (e) если никто в PRE-COMMIT — все abort-ят.

Что на диаграмме

Один координатор (TM, transaction manager) и три участника-БД: orders, inventory, payments — классический distributed transaction поверх трёх шардов. Client инициирует BEGIN tx, координатор оркестрирует три фазы. Три сценария показывают: happy path с тремя round-trip-ами, координатор падает после PreCommit (3PC работает — выигрыш!), сеть partition-ится во время Phase 2 (3PC ломается — divergent state).

Connect-ы в топологии (topology.connect) — это физические соединения. Все сообщения 3PC (CanCommit / PreCommit / DoCommit / ACK) ходят по одним и тем же tcp-edge-ам в обе стороны — анимация использует reverse-flow на тех же edges (см. CLAUDE.md, секция "Edges vs Animation").

Сценарии

1. happy-path-3-phases — три полных round-trip-а. Phase 1: CanCommit? → 3 YES. Phase 2: PreCommit → 3 WAL-записи → 3 ACK. Phase 3: DoCommit → 3 apply → 3 ACK → 200 OK клиенту. Видно цену: на LAN это ~150ms total, на cross-region уже неприемлемо. Сравните с одиночным INSERT на одном узле (~5ms) — distributed transaction любым алгоритмом стоит дорого.

2. coordinator-failure-after-precommit — момент славы 3PC. Все участники получили PreCommit, записали в WAL, ACK-нули. Coordinator падает перед рассылкой DoCommit. У всех участников истёк timer. Они elect нового координатора (роль берёт p1), обмениваются state-ом: «я в PRE-COMMIT» / «я в PRE-COMMIT» / «я в PRE-COMMIT». По инварианту: раз все в PRE-COMMIT, значит координатор дошёл до Phase 2, значит все проголосовали YES, значит commit безопасен. Новый координатор рассылает DoCommit, транзакция завершается. В 2PC участники здесь повисли бы навсегда.

3. partition-breaks-3pc — реальный мир ломает академическую модель. Координатор успел отправить PreCommit только p1. Сеть split-ится: {coord, p1} в одной partition, {p2, p3} в другой. На side A: координатор шлёт DoCommit p1, p1 коммитит. На side B: p2/p3 не получили PreCommit, у них timeout, они рассуждают: «я НЕ в PRE-COMMIT state → значит координатор умер до Phase 2 → safe to abort». p2 и p3 abort-ят. Сеть восстанавливается — orders имеют новую запись, inventory не списан, payments не списан. Broken invariant.

Это и есть демонстрация того, почему 3PC не используют: его корректность опирается на reliable failure detection («если timeout, точно crash»), которая в асинхронной сети недостижима. partition неотличим от crash с точки зрения участника, и 3PC принимает неправильное решение.

Trade-offs (ADR)

ADR-001: Зачем нужна третья фаза — non-blocking при coordinator failure. Решает 2PC blocking problem ценой +50% latency и +50% сетевого трафика. На каждой транзакции лишний round-trip. На p99-чувствительных API (платежи, чекаут) эта надбавка часто несущественна по сравнению с потенциальным простоем в minutes/hours при крахе координатора 2PC. Но условие применимости — узкое.

ADR-002: Почему 3PC всё равно не используется в production. Skeen доказал корректность только в синхронной модели с надёжной failure detection и без network partitions. Реальные сети асинхронны: пакет может задержаться на минуты, partition неотличим от crash, timeout — ненадёжный сигнал. Отрасль пошла другим путём:

• Spanner-style atomic commit через Paxos: каждый shard — Paxos group, commit decision сама реплицируется через consensus. Это даёт fault-tolerance без блокировки и без divergent state при partition. Цена — нужна Paxos-инфраструктура.
• Saga (orchestration или choreography): eventual consistency через compensating actions. Никаких distributed locks. Цена — приложение должно уметь compensate (refund, restock).
• Outbox pattern + idempotent consumers: атомарность через локальную транзакцию + надёжная доставка событий.
• Event sourcing с CRDTs: безконфликтная репликация state-а.

3PC остался теоретическим артефактом для университетских курсов: его изучают, чтобы понять trade-offs и почему «добавим ещё одну фазу» — не путь к надёжности в реальных сетях.

Реальные системы

• Spanner (Google): atomic commit через Paxos. Каждая партиция — Paxos group, transaction coordinator реплицируется через Paxos, decision записывается в Paxos log → partition-tolerant, non-blocking. Это правильный ответ на проблему, которую 3PC пытался решить.
• CockroachDB / YugabyteDB: тоже Paxos/Raft-based atomic commit поверх Multi-Raft.
• X/Open XA (Tuxedo, MS DTC): чистый 2PC, blocking-проблема никуда не делась, требуется heuristic resolution от DBA.
• TiDB: оптимистичный 2PC с Percolator-style commit timestamp через TSO. Не 3PC, но интересный гибрид.
• Production 3PC: автор не знает ни одной известной системы. Вероятно, кто-то когда-то реализовывал — и быстро мигрировал на Saga/consensus.

Anti-patterns

• «Давайте сделаем 3PC между нашими микросервисами через REST» — нет. У вас асинхронная сеть, partition возможен, корректность 3PC не гарантируется. Используйте Saga или outbox.
• Считать timeout надёжным сигналом crash-а — фундаментальная ошибка. В асинхронной сети timeout = «я не знаю, что происходит». Это разные семантики.
• Раздавать роль координатора через «давайте новый координатор — это тот, у кого наименьший node ID» без proper leader election (Raft/Paxos) — split-brain через секунду.
• Хранить PRE-COMMIT state только в памяти участника. Если участник сам тоже падает после ACK, при recovery он должен знать про PRE-COMMIT — это durable WAL запись, не in-memory флаг.
• «Добавим ещё одну фазу, чтобы было ещё надёжнее» (4PC, 5PC) — нет, фундаментально ничего не меняется. FLP impossibility: в полностью асинхронной модели с возможным crash-failure детерминированного консенсуса не существует.

Когда НЕ использовать

Практически — никогда не использовать в production. 3PC ценен как учебный материал: понять, почему «добавить фазу» не спасает, и почему индустрия в итоге выбрала Paxos/Raft.

Конкретно НЕ применять:

• Через WAN или ненадёжную сеть (3PC ломается при partition).
• Когда есть готовое consensus-решение (Raft/Paxos library, Spanner-style БД).
• Когда eventual consistency достаточно — Saga проще и масштабируется лучше.
• В микросервисах, общающихся через message bus — outbox + idempotent consumer закрывают 90% кейсов.
• Если LAN-only datacenter с 2PC: blocking-проблема реальна, но решается обычно failover-ом координатора через HA pair, а не переходом на 3PC.

Если очень хочется non-blocking distributed commit — берите Spanner-style Paxos commit или Calvin-style deterministic ordering, не 3PC.

Дальше читать

• Skeen (1982) — оригинальная статья «Nonblocking Commit Protocols», SIGMOD. Корректность доказана только для synchronous model.
• DDIA, Глава 9 — Кляйпман подробно разбирает 2PC, упоминает 3PC как «теоретическое улучшение, не работающее в реальных сетях».
• System Design Space — 2PC/3PC: https://system-design.space/chapter/distributed-transactions-2pc-3pc
• Spanner paper (Corbett et al., 2012) — как сделать atomic commit правильно: Paxos под капотом.
• «Consensus on Transaction Commit» (Gray & Lamport, 2004) — формализация Paxos Commit, прямой потомок идей 3PC, но корректный в асинхронной сети.
• Концепты: ::concept{slug="two-phase-commit"}, ::concept{slug="cap-theorem"}, ::concept{slug="saga-pattern"}.