Вопрос проверяет понимание видов распределённых транзакций и их применения в микросервисной архитектуре.
Распределённая транзакция затрагивает несколько сервисов или баз данных, и её сложность — в обеспечении согласованности данных при сбоях. Выбор вида транзакции зависит от требований к консистентности и доступности системы.
Это классический подход, гарантирующий, что все участники либо фиксируют изменения, либо откатываются. Основной протокол — двухфазный коммит (2PC): координатор опрашивает участников, затем фиксирует. Применяется в банковских системах, где критична точность.
// Псевдокод 2PC
coordinator.prepare() // фаза 1
if all ok: coordinator.commit() // фаза 2
else: coordinator.rollback()Недостатки: блокировки ресурсов, низкая доступность, сложность реализации.
Здесь нет глобальной атомарности. Вместо этого используется паттерн сага: последовательность локальных транзакций, каждая с компенсирующим действием при ошибке. Это позволяет сервисам работать независимо.
// Сага: бронирование отеля и авиабилета
1. bookHotel() -> success
2. bookFlight() -> fail
3. cancelHotel() // компенсацияСаги бывают хореографические (события) и оркестрационные (центральный координатор). Применяются в e-commerce, заказах, где допустима временная несогласованность.
Атомарные транзакции стоит использовать при жёстких требованиях к консистентности и небольшом числе участников. Компенсирующие — для высоконагруженных микросервисов, где важна доступность и масштабируемость. Выбор зависит от бизнес-требований и допустимой задержки согласования.
Frontend developer
Ментор по Frontend
Полное сопровождение до оффера — без дорогих курсов, с оплатой после трудоустройства
Записаться на консультацию