➡ 2PC (двухфазная фиксация)

2PC (Two-Phase Commit) – паттерн для гарантии атомарности* распределенных транзакций
*атомарность – "всё или ничего": либо выполняются все операции транзакции, либо ни одна

🤩Цель: все участники либо фиксируют изменения, либо откатывают их как единое целое, даже при сбоях.
Это критично для согласованности данных в распределенных системах

🤩Принцип работы: протокол выполняется в две фазы под управлением центрального координатора
 

Роли участников

🤩 Координатор (Coordinator)
Управляет процессом, принимает решение
➖центральный управляющий компонент
➖инициирует протокол 2PC
➖принимает решение (Commit/Abort) на основе голосования ресурсов
➖отвечает за уведомление ресурсов о решении и управление восстановлением при сбоях

🤩Примеры
- транзакционные менеджеры
- СУБД-координатор
- оркестраторы

🤩 Ресурсы (участники)
Выполняют локальные операции, голосуют
➖системы или сервисы, управляющие данными (например, БД)
➖выполняют локальную работу транзакции ("до" коммита)
➖голосуют "Да" (готов к коммиту) или "Нет" (не готов) на фазе Prepare
➖выполняют финальную команду (commit/abort) от координатора

🤩Примеры
- БД
- Очереди сообщений
- Legacy-системы


Фазы

➡️Prepare (Подготовка)

🟡 Координатор ➡️ Ресурсы: координатор рассылает ресурсам команду prepare (запрос голосования)
🟡 Ресурсы:
- проверяют возможность коммита своей части транзакции (проверка ограничений, конфликтов, запись в локальный лог для восстановления)
- блокируют данные (локальные блокировки)
- проверяют возможность коммита
🟡 Голосование ресурсов (отправляют координатору):
- vote_commit (если готов)
- vote_abort (если не готов) и выполняют локальный откат

⬅️Commit (Фиксация) / Abort (Отмена)

Если все vote_commit:
🔘 Координатор  ➡️Ресурсы: рассылает команду commit
🔘 Ресурсы фиксируют изменения, разблокируют данные
- фиксируют изменения данных
- освобождают блокировки
- отправляют координатору ack (подтверждение)
🔘 Координатор, получив все ack, завершает транзакцию

Если хотя бы один vote_abort (или таймаут):
🔘 Координатор  ➡️ Ресурсы: abort (или rollback)
🔘Ресурсы откатывают изменения по журналу
- откатывают свою часть транзакции
- освобождают блокировки
- отправляют координатору ack
🔘 Координатор, получив все ack, завершает транзакцию (как отмененную)


Сценарии работы

🤩 Успешная Транзакция

1. клиент делает перевод 100 руб со счета А (ресурс 1) на счет Б (Ресурс 2)
2. координатор шлет prepare обоим банкам
3. банк А: проверяет наличие 100 руб, блокирует их, голосует "Да"
    банк Б: проверяет можно ли зачислить, голосует "Да"
4. координатор шлет commit
5. банк А: Списывает 100 руб, освобождает блокировку
    банк Б: Зачисляет 100 руб. Оба шлют ack
6. клиент получает подтверждение

🤩Отказ ресурса и восстановление

🟡 Сбой во время prepare: ресурс не ответил
Координатор трактует как vote_abort "Нет" → Откат всех

🟡Сбой ресурса после vote_commit: ресурс упал до получения commit
- при восстановлении ресурс смотрит в свой лог: prepare есть, а commit/abort нет
- ждёт команду координатора (состояние "in doubt")

🟡Сбой координатора после записи решения:
- после записи решения → при рестарте пересылает решение ресурсам
- до записи решения → ресурсы остаются заблокированными до ручного вмешательства


Примеры применения

🤩Legacy-системы: интеграция старых монолитных систем (особенно БД) через стандарт XA
🤩когда критична строгая согласованность в реальном времени на уровне отдельных транзакций между разными системами (счета, ленты транзакций, бухгалтерия)
🤩системы, где ресурсы (БД, очереди) поддерживают интерфейс XA для участия в транзакциях под управлением внешнего TM


📎 Материалы

1. Управление транзакциями в бд
2. Способы управления транзакциями в распределённых ИС. Механизм 2pc
3. 2pc в распределённых транзакциях
4. 2pc и будущее распределённых систем 
5. Распределённые транзакции в микросервисах: от SAGA до 2pc

📚 Распределенные системы. Паттерны проектирования – Брендан Бернс

#проектирование #архитектура


➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу