Sagi i transakcje rozproszone

Saga to długoterminowa transakcja biznesowa w podziale na sekwencję kroków lokalnych w różnych usługach/repozytoriach. Każdy krok ma działanie kompensacyjne, które cofa efekt kroku w częściowej awarii. W przeciwieństwie do 2PC/3PC, sagi nie posiadają światowych zamków i nadają się do mikroelementów, wielowarstwowych i wysokich obciążeń, gdzie ewentualna konsystencja jest akceptowalna.

1) Kiedy wybrać sagi (a kiedy nie)

• Długie/wieloetapowe procesy biznesowe (zamówienie → płatność → rezerwacja → dostawa).
• Różne domeny i repozytoria, w których nie ma wspólnej transakcji.
• Potrzebujesz wysokiej dostępności i skali.

• Atomowość kwasu stałego jest krytyczna (na przykład przenoszenie dużych ilości w tym samym rejestrze).
• Nie ma wyraźnej rekompensaty (nie można „rezerwować” lub anulować efektu).
• Ograniczenia prawne/regulacyjne wymagają ścisłej izolacji i „natychmiastowej” niezmienności.

2) Modele Sagas

1. Saga Orchestrator-Centralny koordynator zarządza krokami i rekompensatami.

Plusy: wyraźny przepływ, kontrola błędów, uproszczona telemetria.
Minusy: punkt centralizacji, ryzyko koordynatora „tłuszczu”.

2. Choreografia (choreografia): brak centrum - kroki są inicjowane przez wydarzenia („service A did X → service B reacts”).

Plusy: słaba łączność, proste skalowanie.
Minusy: trudniej jest śledzić/debugować przepływ, ryzyko „rozpadu” zasad.

3. TCC (Try-Confirm/Anuluj) - Każdy krok to „Spróbuj”, a następnie Potwierdź lub Anuluj.

Plusy: bliżej pseudo-dwufazowego protokołu, zarządzanych zasobów.
Minusy: droższe we wdrażaniu interfejsów; wymaga „Spróbuj” czasu posiadacza.

3) Projekt boiska i kompensacji

Niezmienne: wyraźnie podać, co powinno być prawdziwe „przed/po” kroku (na przykład „pozostałość ≥ 0”).
Transakcja kompensacyjno-odwrotna: jest to logiczne działanie, które anuluje efekt biznesowy (zwrot, zwolnienie, przywrócenie).
Idempotencja: zarówno krok, jak i kompensator muszą być bezpiecznie powtarzane (przez 'operation _ id').
Terminy: każdy krok ma termin; opóźnienie powoduje odszkodowanie.
Efekty bezzwrotne: zapisać je oddzielnie (powiadomienia, e-mail) i umożliwić „najlepszy wysiłek”.

4) Spójność i porządek

Ewentualna spójność: użytkownicy mogą dostrzec rozbieżności czasowe; UX - z „czekać „/spinners/statusy.
Zamówienie według klucza - Grupa kroki przełączania według klucza biznesowego (order_id), aby zamówić zdarzenia.
Deduplikacja - Przechowywanie dziennika przetwarzania ('operation _ id' → status) z TTL.

5) Transport i niezawodność

Outbox pattern-Zapisuje zdarzenie do lokalnej tabeli outbox w ramach tej samej transakcji, a następnie asynchronicznie publikuje go do autobusu.
Sklep Inbox/Idempotency: po stronie konsumenta - dziennik wiadomości już przetworzonych.
Dokładnie raz skutecznie: „outbox + idempotent consumer” daje praktyczne „dokładnie raz”.
DLQ: dla „trujących” wiadomości z bogatymi meta-informacjami i bezpiecznym przekierowaniem.

6) Błąd, przekwalifikowanie, polityka backoff

Powtarzamy tylko idempotentne kroki; operacje pisania - z 'Idempotence-Key'.
Wykładniczy backoff + jitter; ograniczenie prób i skrócony termin sagi.
Przy degradacji systemowej - wyłącznik i wdzięku degradacji (na przykład, anulować drugorzędną część fikcji sagi).
Konflikty biznesowe („409”) - ponowna próba po uzgodnieniu lub zrekompensować i zakończyć.

7) Orkiestra: Obowiązki i struktura

• Śledzenie stanu sagi: „OCZEKUJĄCE → URUCHOMIENIE → KOMPENSOWANIE → ZROBIONE/NIEUDANE”.
• Planowanie kroków, terminy, timeouts, rekolekcje.
• Routing zdarzeń i uruchomienie rekompensaty.
• Idempotencja operacji koordynatora (dziennik poleceń).
• Obserwowalność: korelacja 'saga _ id' w logach/śladach/metrykach.

• Tabele 'saga', 'saga _ step', 'commands', 'outbox'.
• Indeksy na 'saga _ id',' business _ key ',' status ',' next _ run _ at '.

8) Choreografia: zasady i ochrona przed „śnieżną kulą”

Umowy na imprezy: programy i wersioning (Avro/Proto/JSON Schema).
Jasne semantyki: „event fact” vs „command”.
Zatrzymanie łańcucha: usługa, po wykryciu niedopasowania, publikuje zdarzenie 'Failed '/' Compensate'.
Alarmy i alarmy na „niekończące się pętle”.

9) TCC: szczegóły praktyczne

Spróbuj: rezerwy zasobów z TTL.
Potwierdź: commit, zwolnij tymczasowe zamki.
Anuluj: rezerwowy rollback (bez skutków ubocznych).
Kolekcja śmieci: automatyczne anulowanie Try after TTL (idempotent Anuluj).
Potwierdź/anuluj idempotent: powtórzenie jest bezpieczne.

10) Przykład (program słów) - „Zamówienie z płatnością i dostawą”

1. • Zamówienie (lokalne) → skrzynka wybierana: ' Created'.
2. Usługa internetowa: rezerwa „Spróbuj” (TCC); jeśli → "" "Reserved 'succeeds, jeśli'" Nie powiodło się "→ nie powiodło się.
3. Wynalazek: rezerwa produktów; z → „Wynalazek nie powiódł się”.
4. Usługa wysyłkowa - Utwórz gniazdo dostawy (anulowane).
5. Jeśli dowolny 'Nieudany' krok → Orkiestra rozpoczyna kompensacje w odwrotnej kolejności: 'Anuluj wysyłkę' → 'Ekwipunek' → 'Anuluj'.
6. Jeśli wszystko w porządku → „Potwierdź” → „Potwierdzone”.

11) Pseudokod orkiestrowy

pseudo startSaga(saga_id, order_id):
steps = [ReservePayment, ReserveInventory, BookShipment, ConfirmPayment]
for step in steps:
res = execWithRetry(step, order_id)
if!res.ok:
compensateInReverse(steps_done(order_id))
return FAIL return OK

execWithRetry(step, key):
for attempt in 1..MAX:
try:
return step.run(key)    # идемпотентно catch RetryableError:
sleep(backoff(attempt))
catch NonRetryableError:
return FAIL return FAIL

compensateInReverse(done_steps):
for step in reverse(done_steps):
step.compensate()       # идемпотентно

12) Obserwowalność i operacyjne układy SLO

Śledzenie: pojedyncze 'saga _ id', adnotacje' krok ',' próba ',' decyzja '(run/compensate/skip).

• Sukces/błąd sagów (%), średni czas trwania, p95/p99.
• Udział zrekompensowanych sag, główne przyczyny odszkodowania.
• Kolejki/skrzynki zewnętrzne, przekłada się w krokach.
• Dzienniki/audyty: rozwiązania orkiestrowe, identyfikatory zasobów, klucze biznesowe.

13) Testowanie i chaos

Wtryskiwanie błędów do każdego kroku: timeouts, '5xx', konflikty biznesowe.
Zdarzenia pozasądowe, duplikaty, krople.
Długie ogony opóźnienia → sprawdzanie terminów i rekompensaty.
Masowe sagi → sprawdzanie WFQ/DRR i czapki w kolejkach, brak „blokowania head-of-line”.
Redrave z DLQ w krokach i w całej sadze.

14) Wielopoziomowość, regiony, zgodność

Najemca tagów _ id/plan/region 'w zdarzeniach i repozytoriach sagi.
Miejsce zamieszkania: dane/wydarzenia nie opuszczają regionu; międzyregionalne sagi są projektowane jako federacje lokalnych sag + imprez agregacyjnych.
Priorytety: sagi VIP mają większą wagę kontyngentu; izolacja pracowników na najemcę.

15) Lista kontrolna przedsprzedaży

• Każdy krok ma wyraźny kompensator, oba są idempotentne.
• Wybrany szablon: orkiestra/choreografia/TSS; opisano limity odpowiedzialności.
• Outbox/Inbox implemented, deduplication by 'operation _ id'.
• Polityka retrasy: backoff with jitter, spróbuj limitów i ogólny termin sagi.
• Umowy o zdarzenia są zmieniane, istnieje zatwierdzenie programu.
• Konfiguracja DLQ i Secure Release.
• Telemetria: mierniki, odwzorowanie, korelacja "saga _ id'.
• Operacyjne playbooks: ręczne anulowanie/siłowe potwierdzenie, odblokowanie sagów „hung”.
• Chaos i test obciążenia przejść, SLO/budżet błędu zdefiniowane.

16) Typowe błędy

Nie ma kompensatora lub jest „nieczysty” (ma skutki uboczne).
Nie ma idempotencji/dedup - podwójne i „huśtawki” państw.
„Saga w Sadze” bez wyraźnych granic - cykli i wzajemnych zamków.
Nie ma terminów → „wieczne” sagi i wycieki zasobów.
Orkiestra przechowuje stan „w pamięci” bez stabilnego sklepu.
Choreografia bez centrum telemetrycznego → „niewidzialne” awarie.
Opaque UX: Użytkownicy nie widzą statusów pośrednich.

17) Szybkie przepisy kulinarne

Klasyka SaaS: orkiestra + skrzynka odbiorcza/skrzynka odbiorcza, wykładnicze backoff, DLQ, statusy sagi w UI.
Silne zasoby niezmienne: TCC z rezerwą TTL i GC Anuluj.
Duża objętość/obciążenie: choreografia wydarzeń + ścisła iempotencja i kluczowe wskaźniki.
Wielobranżowe: sagi lokalne + kruszywa końcowe; unikać globalnych zamków.

Wniosek

Sagi są sposobem na uzyskanie przewidywalnej spójności w systemach rozproszonych bez globalnych blokad. Przejrzyste kompensatory, idempotencja, niezawodna dostawa (skrzynka odbiorcza/skrzynka odbiorcza), dyscyplina timeout i retray, a także telemetria i playbook są kluczem do zapewnienia, że złożone procesy biznesowe pozostają stabilne i czytelne wraz ze wzrostem obciążenia, liczby usług i geografii.