Через какой паттерн можно провести распределенную транзакцию

Паттерны для распределенных транзакций в распределенных системах

Распределенная транзакция — это операция, охватывающая несколько независимых систем или сервисов, требующая гарантий атомарности (все шаги выполняются или ни один) и консистентности данных между ними. В микросервисных архитектурах и распределенных системах классические ACID-транзакции с двухфазным коммитом (2PC) часто неприменимы из-за проблем с производительностью, надежностью и необходимостью слабой связанности. Поэтому используются альтернативные паттерны.

SAGA Pattern (Сага)

Это основной и наиболее популярный паттерн для управления длительными распределенными транзакциями в микросервисах. Он заменяет единую ACID-транзакцию на последовательность локальных транзакций в каждом сервисе, с компенсирующими транзакциями для отката.

Как работает Saga

• Хореография (Choreography): Каждый сервис выполняет свою локальную транзакцию и публикует событие (например, через Kafka, RabbitMQ). Следующий сервис подписывается на это событие и выполняет свой шаг. Если произошла ошибка, сервис публикует событие компенсации, которое запускает компенсирующие транзакции в предыдущих сервисах.

// Пример структуры события для Saga в хореографии
type OrderCreatedEvent struct {
    OrderID   string `json:"orderId"`
    UserID    string `json:"userId"`
    Amount    int    `json:"amount"`
}

// Сервис оплаты, подписанный на событие создания заказа
func PaymentService(event OrderCreatedEvent) error {
    // Локальная транзакция: списание средств
    err := processPayment(event.UserID, event.Amount)
    if err != nil {
        // Публикуем событие компенсации
        publishCompensationEvent(event.OrderID, "payment_failed")
        return err
    }
    publishPaymentSuccessEvent(event.OrderID)
    return nil
}

• Оркестрация (Orchestration): Центральный координатор (оркестратор) управляет потоком выполнения. Он вызывает каждый сервис по очереди и, при ошибке, запускает компенсирующие транзакции.

// Пример оркестратора Saga
type SagaOrchestrator struct {
    steps []SagaStep
}

func (o *SagaOrchestrator) Execute(order Order) error {
    for _, step := range o.steps {
        err := step.Execute(order)
        if err != nil {
            // Откатываем все выполненные шаги
            o.Rollback(order)
            return err
        }
    }
    return nil
}

func (o *SagaOrchestrator) Rollback(order Order) {
    for i := len(o.steps) - 1; i >= 0; i-- {
        o.steps[i].Compensate(order)
    }
}

Преимущества Saga: Отсутствие долгосрочных блокировок ресурсов, высокая масштабируемость, поддержка слабой связанности. Недостатки: Сложность реализации компенсирующих транзакций, возможная временная неконсистентность данных.

Two-Phase Commit (2PC) — двухфазный коммит

Традиционный паттерн из мира баз данных, но может адаптироваться для распределенных систем. Координатор сначала запрашивает все участники о готовности коммита (фаза подготовки), затем, если все согласны, отправляет команду коммита (фаза коммита).

// Упрощенная структура координатора 2PC
type Coordinator struct {
    participants []Participant
}

func (c *Coordinator) ExecuteTransaction() error {
    // Фаза 1: Prepare
    for _, p := range c.participants {
        if !p.Prepare() {
            return errors.New("prepare phase failed")
        }
    }
    
    // Фаза 2: Commit
    for _, p := range c.participants {
        if !p.Commit() {
            // В случае ошибки на фазе коммита требуется сложный recovery
            return errors.New("commit phase failed")
        }
    }
    return nil
}

Проблемы 2PC в распределенных системах: Координатор становится точкой отказа, высокие накладные расходы на коммуникацию, блокировки ресурсов на время подготовки.

Transactional Outbox (Транзакционный исходящий ящик)

Паттерн для гарантированной доставки событий в контексте распределенных транзакций, когда нужно сохранить данные в локальной БД и опубликовать событие атомарно.

• Сохраняем данные и событие (в таблицу outbox) в одной локальной транзакции.
• Отдельный процесс (релей или лог-трекер) периодически выбирает события из outbox и публикует их в брокер сообщений.

// Пример использования outbox в Go
func CreateOrder(order Order) error {
    tx, err := db.Begin()
    if err != nil {
        return err
    }
    
    // 1. Сохраняем заказ в основную таблицу
    err = tx.Exec("INSERT INTO orders ...", order)
    if err != nil {
        tx.Rollback()
        return err
    }
    
    // 2. Сохраняем событие в outbox в той же транзакции
    event := OutboxEvent{
        Type:    "OrderCreated",
        Payload: order,
    }
    err = tx.Exec("INSERT INTO outbox ...", event)
    if err != nil {
        tx.Rollback()
        return err
    }
    
    return tx.Commit() // Транзакция коммитится атомарно
}

Преимущества: Атомарность сохранения данных и события, избегание дублирования событий. Недостатки: Добавляется дополнительная таблица и процесс релея.

Compensating Transaction (Компенсирующая транзакция)

Не самостоятельный паттерн, но ключевой компонент Saga и других подходов. Это операция, логически обратная основной, которая отменяет ее эффект (например, возврат платежа после неудачного резервирования товара).

Выбор паттерна

Критерии выбора:

• Сага подходит для большинства бизнес-процессов в микросервисах (заказ, бронирование).
• Транзакционный Outbox необходим, когда требуется надежная публикация событий после локальных транзакций.
• 2PC может использоваться в системах с сильной связанностью и где допустимы блокировки (например, распределенные БД).

В современных распределенных системах чаще применяется комбинация паттернов: Saga с оркестрацией для управления бизнес-процессом и Transactional Outbox в каждом сервисе для надежной коммуникации событий. Это позволяет достичь баланса между консистентностью, доступностью и слабой связанностью.