Distributed transactions и 2PC¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

2PC координирует atomic commit нескольких resource managers: prepare, затем decision commit/abort. Это не сам по себе consensus/replication protocol и не автоматическая поддержка произвольного HTTP API. PostgreSQL PREPARE TRANSACTION относится к внешне координируемой transaction, а не к prepared SQL statement.

flowchart LR
  Coordinator --> Prepare[Prepare participants]
  Prepare --> Durable[Participants retain prepared state]
  Durable --> Decision[Durable global decision]
  Decision --> Finish[Commit or abort all]
  Durable -. coordinator unavailable .-> InDoubt[Wait for recovery decision]

Операция чтения или записи по шагам¶

Координатор просит participants prepare; каждый устойчиво фиксирует готовность и удерживает нужные locks. После всех yes координатор устойчиво записывает decision и рассылает commit. Если yes не все, решает abort. Client timeout после durable decision не даёт права выбрать иной исход.

Консистентность, отказ и восстановление¶

Coordinator crash между prepare и decision delivery оставляет in-doubt participants; классический 2PC может блокировать. Replicated coordinator log повышает устойчивость при корректном протоколе, но не отменяет необходимости recovery decision. Manually commit prepared допустим только при установленном глобальном исходе.

Выбор, эксплуатация и ограничения¶

2PC полезен при поддержке всеми participants и строгом atomicity требовании; цена — locks, log fsync, coordinator HA и сложность operations. Saga разделяет commits и компенсирует бизнес-эффекты, но не эквивалентна rollback/isolation 2PC. Outbox решает DB+message intent без arbitrary cross-system ACID.

Типичные ошибки проектирования¶

Оставить prepared transactions без monitoring; называть Saga распределённой serializable transaction. Вопрос: 2PC даёт exactly-once email? Нет, email service должен участвовать в корректном протоколе либо side effect проектируется отдельно.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Составьте state machine coordinator/participant при потере ACK и перезапуске. Для ledger→provider payout выберите atomic boundary и покажите, какие действия могут потребовать compensation/reconciliation.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.