Отсутствие гарантий завершения Saga/TCC-транзакций в сетях с разделением #7

New Issue

2026-08-17T21:24:47Z

gvsafronov commented

2026-08-17 21:24:47 +00:00

Проблема

Реализация распределённого координатора кластера на основе алгоритма консенсуса Raft реализует распределённые транзакции через паттерны Saga (SagaManager) и TCC (TCCManager). Однако текущая реализация не предоставляет формальных гарантий финальности транзакций при сетевых разделениях.

Симптомы. При потере лидера кластера Raft транзакции могут оставаться в промежуточных состояниях (компенсация, подтверждение). Механизм компенсации не имеет гарантий доставки — если узел с неудачной компенсацией не перезапустится, транзакция зависнет навсегда. Отсутствует единый журнал транзакций для восстановления после отказа координатора. TCCManager использует таймауты, но не имеет механизма повторных попыток для фаз Confirm/Cancel.

Архитектурная проблема

Как обеспечить атомарность и финальность распределённых транзакций в системе с возможными частичными отказами при использовании паттернов Saga/TCC?

Предлагаемые направления исследований

Координатор транзакций с журналом упреждающей записи (Write-Ahead Log) — реализация выделенного координатора транзакций, который сохраняет состояние каждого шага в журнал упреждающей записи перед выполнением, обеспечивая возможность восстановления после отказа координатора.
Идемпотентная компенсация — проектирование всех операций компенсации как идемпотентных, гарантируя, что повторное выполнение даёт тот же результат и допускает безопасные повторные попытки.
Синхронизация с Raft — использование журнала Raft в качестве журнала транзакций, гарантируя, что изменения состояния транзакций реплицируются и являются долговечными в масштабах всего кластера.
Протокол 2PC для Saga — адаптация семантики двухфазной фиксации для шагов Saga, где каждый шаг подтверждает готовность перед продолжением транзакции, предотвращая частичное выполнение.
Механизм обнаружения осиротевших транзакций — реализация механизма обнаружения «осиротевших» транзакций, потерявших своего координатора, с автоматическими политиками восстановления или очистки.
Политики таймаутов и повторных попыток транзакций — реализация настраиваемых таймаутов с экспоненциальной задержкой для повторных попыток неудачных операций и компенсаций.
Мониторинг распределённых транзакций — добавление мониторинга и наблюдаемости состояний транзакций с оповещениями о зависших транзакциях.

Соответствующие файлы с исходным кодом:

internal/cluster/raft_coordinator.go (строки 1800–2100, Saga/TCC)
internal/cluster/raft_coordinator.go (RecoveryManager)

**Проблема** Реализация распределённого координатора кластера на основе алгоритма консенсуса Raft реализует распределённые транзакции через паттерны Saga (SagaManager) и TCC (TCCManager). Однако текущая реализация не предоставляет формальных гарантий финальности транзакций при сетевых разделениях. **Симптомы.** При потере лидера кластера Raft транзакции могут оставаться в промежуточных состояниях (компенсация, подтверждение). Механизм компенсации не имеет гарантий доставки — если узел с неудачной компенсацией не перезапустится, транзакция зависнет навсегда. Отсутствует единый журнал транзакций для восстановления после отказа координатора. TCCManager использует таймауты, но не имеет механизма повторных попыток для фаз Confirm/Cancel. **Архитектурная проблема** Как обеспечить атомарность и финальность распределённых транзакций в системе с возможными частичными отказами при использовании паттернов Saga/TCC? **Предлагаемые направления исследований** 1. **Координатор транзакций с журналом упреждающей записи (Write-Ahead Log)** — реализация выделенного координатора транзакций, который сохраняет состояние каждого шага в журнал упреждающей записи перед выполнением, обеспечивая возможность восстановления после отказа координатора. 2. **Идемпотентная компенсация** — проектирование всех операций компенсации как идемпотентных, гарантируя, что повторное выполнение даёт тот же результат и допускает безопасные повторные попытки. 3. **Синхронизация с Raft** — использование журнала Raft в качестве журнала транзакций, гарантируя, что изменения состояния транзакций реплицируются и являются долговечными в масштабах всего кластера. 4. **Протокол 2PC для Saga** — адаптация семантики двухфазной фиксации для шагов Saga, где каждый шаг подтверждает готовность перед продолжением транзакции, предотвращая частичное выполнение. 5. **Механизм обнаружения осиротевших транзакций** — реализация механизма обнаружения «осиротевших» транзакций, потерявших своего координатора, с автоматическими политиками восстановления или очистки. 6. **Политики таймаутов и повторных попыток транзакций** — реализация настраиваемых таймаутов с экспоненциальной задержкой для повторных попыток неудачных операций и компенсаций. 7. **Мониторинг распределённых транзакций** — добавление мониторинга и наблюдаемости состояний транзакций с оповещениями о зависших транзакциях. **Соответствующие файлы с исходным кодом:** - `internal/cluster/raft_coordinator.go` (строки 1800–2100, Saga/TCC) - `internal/cluster/raft_coordinator.go` (RecoveryManager)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: gvsafronov/futriix#7