Saga-pattern və paylanmış əməliyyatlar

Saga-pattern və paylanmış əməliyyatlar

1) Niyə dastanlar lazımdır

Klassik 2PC (iki fazalı fiksasiya) zəif ölçülür, nasazlıqlar altında mürəkkəbləşir və resursları bloklayır. Saga ümumi biznes prosesini lokal əməliyyatların (addımların) ardıcıllığına bölür, hər biri müstəqil olaraq birləşir. Uğursuz olduqda, sonrakı addımlar ləğv edilir və artıq yerinə yetirilənlər əks əməliyyatlarla kompensasiya olunur.
Nəticə: qlobal kilid olmadan idarə olunan eventual consistency, yüksək canlılıq və aydın bərpa protokolu.

2) Əsas modellər

2. 1 Orkestr

Xüsusi dastan koordinatoru addımları idarə edir: komandalar göndərir, cavablar/hadisələr gözləyir, kompensasiyalar başlayır.
Üstünlüklər: mərkəzləşdirilmiş nəzarət, sadə müşahidə, aydın müddət. Mənfi cəhətləri: əlavə komponent.

2. 2 Xoreoqrafiya

Koordinator yoxdur; xidmətlər bir-birinin hadisələrinə cavab verir («OrderPlaced» → «PaymentCaptured» → «InventoryReserved»...).
Üstünlüklər: zəif bağlılıq. Mənfi cəhətləri: izləmək daha çətindir, dəqiq qaydalar olmadan «ölüm rəqsi» riski.

2. 3 TCC (Try-Confirm/Cancel)

1. Try - hazırlıq/ehtiyat,

2. Confirm - fiksasiya,

3. Cancel - geri.

Zəmanət daha yüksəkdir, lakin daha çətin müqavilələr və vaxtlar ehtiyat.

3) Addım və kompensasiya müqavilələri

Hər addım = yerli əməliyyat + kompensasiya (idempotent, təkrar icazə).
Kompensasiya tamamilə «dünyanı geri qaytarmaq» məcburiyyətində deyil - kifayət qədər domen ekvivalentliyi (məsələn, «ödənişi silmək» əvəzinə «geri ödəmə»).
Qeyri-variantları müəyyən edin: pul üçün - balans mənfi getmir; sifarişlər üçün - «asılmış» statuslar yoxdur.
Vaxtı keçmiş cəhdlər üçün/TTL ehtiyatları və «garbage collector» daxil edin.

4) Uyğunluq və çatdırılma semantikası

Mesajların çatdırılması: at-least-once (defolt) → bütün əməliyyatlar idempotent olmalıdır.
Sifariş: korrelyasiya açarı ilə vacibdir (məsələn, 'order _ id', 'player _ id').
Exactly-once dastanın məqsədi deyil; idempotent açarları, outbox/inbox və düzgün kommitasiya vasitəsilə effektiv bərabərlik əldə edirik.

5) Dastanın vəziyyəti və onun log

• 'saga _ id', 'correlation _ id', cari status (Running/Completed/Compensating/Compensated/Failed),
• addım və onun dəyişənləri (ID ödənişlər/ehtiyatlar),
• hadisələrin/qərarların tarixi (jurnal), taymstamplar, müddətlər, retrajların sayı.

• Ayrı Saga Store (cədvəl/sənəd) koordinator üçün mövcuddur.
• Xoreoqrafiya üçün - ümumi topikdə status hadisələrini dərc edən dastanın yerli «agentləri».

6) Etibarlı nəşr nümunələri: outbox/inbox

Outbox: addım dəyişiklik kommitit və bir əməliyyat outbox cədvəl hadisə/komanda qeyd; worker şin dərc edir.
Inbox: istehlakçı emal edilmiş 'message _ id' → dedup + idempotentlik cədvəlini aparır.
Uğurlu yan təsirdən sonra kommitim offset/ACK (Kafka/RabbitMQ) - daha əvvəl deyil.

7) Dastan addımlarının layihələndirilməsi

7. 1 Nümunə (iGaming/e-ticarətdə alış)

1. PlaceOrder → 'PENDING' statusu.
2. AuthorizePayment (Try) → `payment_hold_id`.
3. ReserveInventory → `reservation_id`.
4. CapturePayment (Confirm).
5. FinalizeOrder → `COMPLETED`.

• (3) uğursuz olarsa → 'CancelPaymentHold';
• (4) sonra uğursuz olduqda (3) → 'ReleaseInventory';
• (5) iflasa uğradıqda → 'RefundPayment' və 'ReleaseInventory'.

7. 2 Müddət/retraj

Maksimum N retrains + jitter eksponensial gecikmə ilə.
Artıq olduqdan sonra - «Compensating» -ə keçid.
Hər addım üçün next_attempt_at və deadline_at saxlayın.

8) Orkestrator vs platforma

• Yüngül ev orkestratoru (mikroservis + Saga cədvəli).
• Platformalar: Temporal/Cadence, Camunda, Netflix Conductor, Zeebe - zamanlayıcılar, retrajlar, uzun ömürlü workflow, görünürlük və veb konsol verir.
• Xoreoqrafiya üçün hadisə kataloqundan və ciddi status/açar sazişindən istifadə edin.

9) İnteqrasiya protokolları

9. 1 Asinxron (Kafka/RabbitMQ)

Komandalar: 'payments. authorize. v1`, `inventory. reserve. v1`.
Hadisələr: 'payments. authorized. v1`, `inventory. reserved. v1`, `payments. captured. v1`, `payments. refunded. v1`.
Partiya açarı = 'order _ id '/' player _ id' sifariş üçün.

9. 2 Addım daxilində sinxron (HTTP/gRPC)

«Qısa» addımlar üçün icazə verilir, lakin həmişə zaman/retraut/idempotentlik və asenkron kompensasiyada fallback ilə.

10) İdempotentlik və açarlar

Komandalar və kompensasiyalar üçün 'idempotency _ key' -yə müraciət edin.
Yan təsirlər (DB/yazma) şərti olaraq yerinə yetirilir: «hələ 'idempotency _ key' görməmişsinizsə yerinə yetirin».
Kompensasiya da idempotentdir: 'RefundPayment (id = X)' təkrar təhlükəsizdir.

11) Səhv emalı

• Transient (şəbəkə/vaxt) → retrai/backoff.
• Biznes (kifayət qədər vəsait, limitlər) → dərhal kompensasiya/alternativ yol.
• Irrecoverable (invariant pozuntusu) → əl müdaxiləsi, «əl» kompensasiyası.
• Həll matrisini qurun: səhv növü → hərəkət (retry/compensate/escalate).

12) Müşahidə və SLO saqa

• End-to-end latency dastan (p50/p95/p99).
• Success rate (kompensasiya olmadan tamamlanmış pay).
• Mean time to compensate и compensation rate.
• Orphaned sagas (asma) və GC qədər vaxt.
• Tracking: 'trace _ id '/' saga _ id' kimi span link arasında addımlar; büdcə səhvləri üçün burn-rate metrik.

Logi: Hər bir saga status dəyişikliyi = səbəb ilə strukturlaşdırılmış giriş.

13) Nümunələr (psevdokod)

13. 1 Orkestrator (fikir)

python def handle(OrderPlaced e):
saga = Saga. start(e. order_id)
saga. run(step=authorize_payment, compensate=cancel_payment)
saga. run(step=reserve_inventory, compensate=release_inventory)
saga. run(step=capture_payment, compensate=refund_payment)
saga. run(step=finalize_order, compensate=refund_and_release)
saga. complete()

def run(step, compensate):
try:
step () # local transaction + outbox except Transient:
schedule_retry()
except Business as err:
start_compensation(err)

13. 2 Outbox (cədvəl ideyası)

outbox(id PK, aggregate_id, event_type, payload, created_at, sent_at NULL)
inbox(message_id PK, processed_at, status)
saga(order_id PK, state, step, next_attempt_at, deadline_at, context JSONB)
saga_log(id PK, order_id, time, event, details)

13. 3 Xoreoqrafiya (mövzu ideyaları)

`orders. placed '→ istehlakçılar: ' payments. authorize`, `inventory. reserve`

`payments. authorized` + `inventory. reserved` → `orders. try_finalize`

Hər hansı bir imtina → 'orders. compensate '→ başlanğıc' payments. cancel/refund`, `inventory. release`.

14) 2PC və ES ilə müqayisə

2PC: güclü uyğunluq, lakin kilidləmə, dar yerlər, «mis borular».
Saga: eventual consistency, kompensasiya və telemetriya intizamı lazımdır.
Event Sourcing: hadisələri həqiqət mənbəyi kimi saxlayır; üzərində saqalar təbiidir, lakin miqrasiyaların/snapshotların mürəkkəbliyini əlavə edir.

15) Təhlükəsizlik və uyğunluq

Nəqliyyat təhlükəsizliyi (TLS/mTLS), ACL per topic/queue.
Hadisələrdə - minimum PII, həssas sahələrin şifrələnməsi, tokenizasiya.
Saqalara və kompensasiya jurnallarına giriş auditi.
Xarici provayderlərlə SLA (ödənişlər/çatdırılma) = son tarixlər və retraj limitlərinin parametrləri.

16) Giriş çek siyahısı (0-45 gün)

0-10 gün

Namizəd prosesləri seçin (multiservice, kompensasiya ilə).
Model seçin (orkestr/xoreoqrafiya/TSS) və korrelyasiya açarı.
Addımlar/kompensasiyalar, invariantlar və müddətləri təsvir edin. 'saga', 'outbox', 'inbox' cədvəllərini qaldırın.

11-25 gün

backoff ilə outbox/inbox, idempotent və retras daxil edin.
İlk dastanları deployt; SLI/SLO dashboard və track əlavə edin.
Runbook kompensasiya (əl daxil olmaqla) və eskalasiya yaz.

26-45 gün

Avtomatlaşdırın GC «asılı» saqlar, periodik yenidən başlamalar/müddətinə davam.
Oyun-day keçirin: addım atma, həddini aşma, brokerin əlçatmazlığı.
Hadisə müqavilələrini (versiyalar, uyğunluq) standartlaşdırın, «saqlar kataloqu» yaradın.

17) Anti-nümunələr

«Kompensasiya = DB-dən delete» domen düzgün əks hərəkət əvəzinə.
No outbox/inbox → hadisə itkisi/ikiqat effekt.
Jitter → özü-DDoS asılılığı olmadan retrailer.
«Emal gedir» olmadan oxu üzərində güclü uyğunluq gözləmək....
bütün → monolit nəzarət üçün bir nəhəng orkestrator.
Görünmədən ümumi xoreoqrafiya və SLA → idarəolunmaz rəqs.
Son tarixlərə məhəl qoymamaq → əbədi ehtiyatlar/holdlər.

18) Yetkinlik metrikası

Kritik proseslərin ≥ 90% -i saqalar/kompensasiyalar ilə örtülür və təsvir edilmiş invariantlara malikdir.
Outbox/inbox bütün prodüser/ Tier-0/1 məsləhətçiləri üçün inteqrasiya olunur.
SLO: p95 end-to-end saqa normal, success rate sabit, orphaned <hədəf.
Şəffaf izləmə və daşbordlar «addımlarla», burn-rate alert.
Rüblük game-day və manual runbook kompensasiya yoxlama.

19) Nəticə

Saga paylanmış sistemlər üçün praktik uyğunluq müqaviləsidir: aydın addımlar və əks hərəkətlər, nəşr intizamı (outbox/inbox), son tarixlər və retralar, müşahidə və kompensasiya prosesləri. Model seçin (orkestr/xoreoqrafiya/TSS), invariantları və açarları düzəldin, prosessorları idempotent edin - və multiservice biznes prosesləriniz bahalı 2PC olmadan proqnozlaşdırıla bilən və sabit olacaq.