Saga-pattern va taqsimlangan tranzaksiyalar

Saga-pattern va taqsimlangan tranzaksiyalar

1) Dostonlar nima uchun kerak?

Klassik 2PC (ikki fazali fiksatsiya) yomon ko’payadi, nosozliklar ostida murakkab va resurslarni bloklaydi. Saga umumiy biznes jarayonini har biri mustaqil ravishda birlashtiriladigan lokal tranzaksiyalar (qadamlar) ketma-ketligiga ajratadi. Muvaffaqiyatsiz tugaganda keyingi qadamlar bekor qilinadi, bajarilgan qadamlar esa qaytish operatsiyalari bilan qoplanadi.
Natija: global blokirovkasiz boshqariladigan eventual consistency, yuqori chidamlilik va aniq tiklanish protokoli.

2) Bazaviy modellar

2. 1 Orkestr

Tanlangan dastani muvofiqlashtiruvchi boshqaradi: buyruqlarni yuboradi, javoblarni kutadi, kompensatsiyalarni boshlaydi.
Ijobiy tomonlari: markazlashtirilgan nazorat, oddiy kuzatuv, aniq muddatlar. Kamchiliklar: qo’shimcha komponent.

2. 2 Xoreografiya

Koordinator yoʻq; xizmatlar bir-birining voqealariga munosabat bildiradi («OrderPlaced» → «PaymentCaptured» → «InventoryReserved»...).
Afzalliklari: zaif bog’liqlik. Kamchiliklar: aniq qoidalarsiz «o’lim raqsi» xavfini kuzatish qiyinroq.

2. 3 TCC (Try-Confirm/Cancel)

1. Try - tayyorgarlik/zaxira,

2. Confirm - fiksatsiya,

3. Cancel - orqaga qaytish.

Kafolatlar yuqori, ammo kontraktlar va zaxiralar taymautlari murakkabroq.

3) Qadamlar va kompensatsiyalar kontraktlari

Har bir qadam = lokal tranzaksiya + kompensatsiya (idempotent, takrorlashga ruxsat beradi).
Kompensatsiya to’liq «dunyoni qaytarish» shart emas - etarli domen ekvivalentligi (masalan, «to’lovni olib tashlash» o’rniga «qaytarish to’lovi»).
Invariantlarni aniqlang: pul uchun - balans minusga ketmaydi; buyurtmalar uchun - «osilgan» maqomlar mavjud emas.
Kechiktirilgan urinishlar uchun muddatlar/TTL zaxiralari va «garbage collector» ni kiriting.

4) Yetkazib berishning muvofiqligi va semantikasi

Xabar yetkazib berish: at-least-once (defolt) → barcha operatsiyalar idempotent boʻlishi kerak.
Tartib: korrelyatsiya kalitida muhim (masalan,’order _ id’,’player _ id’).
Exactly-once - dastaning maqsadi emas; idempotent kalitlar, outbox/inbox va to’g "ri kommitatsiya orqali bir marotaba samarali bo’lishga erishamiz.

5) Saga va uning log holati

• ’saga _ id’,’correlation _ id’, joriy maqom (Running/Completed/Compensating/Compensated/Failed),
• qadam va uning o’zgaruvchanlari (IDs to’lovlar/zaxiralar),
• voqealar/qarorlar tarixi (jurnali), taymstemplar, muddatlar, retrajlar soni.

• Individual Saga Store (jadval/hujjat).
• Xoreografiya uchun - maqom voqealarini umumiy topikda chop etuvchi dostonning mahalliy «agentlari».

6) Ishonchli nashr patterni: outbox/inbox

Outbox: qadam oʻzgarishlarni birlashtiradi va hodisa/buyruqni bitta tranzaksiyada outbox jadvaliga yozib oladi; vorker shinaga joylashtiradi.
Inbox: isteʼmolchi qayta ishlangan’message _ id’→ dedup + idempotentlik jadvalini yuritadi.
Muvaffaqiyatli nojo’ya ta’sirdan so’ng kommitim offset/ACK (Kafka/RabbitMQ) - bundan oldin emas.

7) Doston qadamlarini loyihalash

7. 1 Misol (iGaming/e-commerce orqali xarid qilish)

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

• (3) muvaffaqiyatsiz tugagan bo’lsa →’CancelPaymentHold’;
• agar (4) (3) →’ReleaseInventory’dan keyin muvaffaqiyatsizlikka uchragan bo’lsa;
• (5) muvaffaqiyatsiz tugagan taqdirda →’RefundPayment’va’ReleaseInventory’.

7. 2 muddat/retray

Maksimal N retrayev eksponensial kechikish + jitter.
Ortib ketgandan so’ng - «Compensating» ga o’tish.
Har bir qadam uchun next_attempt_at va deadline_at saqlang.

8) Orkestrator vs platforma

• Yengil uy orkestratori (mikroservis + Saga jadvali).
• Platformalar: Temporal/Cadence, Camunda, Netflix Conductor, Zeebe - taymerlar, retrajlar, uzoq umr ko’radigan mashg’ulotlar, ko’rinish va veb-konsol beradi.
• Xoreografiya uchun voqealar katalogi va status/kalitlar to’g’risidagi qat’iy kelishuvdan foydalaning.

9) Integratsiya bayonnomalari

9. 1 Asinxron (Kafka/RabbitMQ)

Buyruqlar:’payments. authorize. v1`, `inventory. reserve. v1`.
Hodisalar:’payments. authorized. v1`, `inventory. reserved. v1`, `payments. captured. v1`, `payments. refunded. v1`.
Partiya kaliti =’order _ id ’/’ player _ id’uchun.

9. 2 Qadam ichida sinxron (HTTP/gRPC)

«Qisqa» qadamlar uchun ruxsat etiladi, lekin har doim taymaut/retray/idempotentlik va asinxron kompensatsiya uchun fallback bilan.

10) Idempotentlik va kalitlar

Buyruqlar va kompensatsiyalarni’idempotency _ key’ga topshiring.
Nojo’ya ta’sirlar (DBga yozish/hisobdan chiqarish) «agar’idempotency _ key’hali ko’rilmagan bo’lsa, bajarish» shartli ravishda bajariladi.
Kompensatsiyalar ham idempotentdir:’RefundPayment (id = X)’takrorlash xavfsiz.

11) Xatolarni qayta ishlash

• Transient (tarmoqlar/taymautlar) → retrai/backoff.
• Business (mablag’lar, limitlar etarli emas) → darhol kompensatsiya/muqobil yo’l.
• Irrecoverable (invariantning buzilishi) → qo’lda aralashish, «qo’lda» kompensatsiya.
• Xato turi → harakat (retry/compensate/escalate).

12) Kuzatuvchanlik va SLO so’g "i

• End-to-end latency sagi (p50/p95/p99).
• Success rate (kompensatsiyasiz tugallanganlar ulushi).
• Mean time to compensate и compensation rate.
• Orphaned sagas (osilgan) va GC gacha vaqt.
• Trace:’trace _ id ’/’ saga _ id’span link sifatida qadamlar orasida; xato budjetlari uchun burn-rate metrikasi.

Logi: saga maqomining har bir o’zgarishi = sababi bilan tuzilgan yozuv.

13) Misollar (psevdokod)

13. 1 Orkestrator (g’oya)

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 (jadval gʻoyasi)

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 Xoreografiya (mavzular g’oyalari)

`orders. placed’→ isteʼmolchilar: ’payments. authorize`, `inventory. reserve`

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

Har qanday rad etish →’orders. compensate’→ boshlanmoqda’payments. cancel/refund`, `inventory. release`.

14) 2PC va ES bilan taqqoslash

2PC: kuchli muvofiqlik, lekin qulflash, tor joylar, «mis quvurlar».
Saga: eventual consistency, kompensatsiya va telemetriya intizomi kerak.
Event Sourcing: voqealarni haqiqat manbai sifatida saqlaydi; dastalari tabiiy, lekin migratsiya/snapshotlarning murakkabligini qo’shadi.

15) Xavfsizlik va komplayens

Transport xavfsizligi (TLS/mTLS), ACL per topic/queue.
Hodisalarda - minimal PII, sezgir maydonlarni shifrlash, tokenlash.
Saga va kompensatsiya jurnallaridan foydalanish auditi.
tashqi provayderlar bilan SLA (to’lovlar/yetkazib berish) = muddatlar va retray limitlari parametrlari.

16) Joriy etish chek-varaqasi (0-45 kun)

0-10 kun

Nomzod jarayonlarni ajrating (multiservis, kompensatsiya bilan).
Model (orkestr/xoreografiya/TSS) va korrelyatsiya kalitini tanlang.
Kompensatsiya, invariantlar va muddatlarni tavsiflang. ’saga’,’outbox’,’inbox’jadvallarini ko’taring.

11-25 kun

outbox/inbox, idempotent va backoff retrajlarini kiriting.
Birinchi dostonlarni qaytaring; SLI/SLO dashbordlari va trassalarini qoʻshing.
Runbook kompensatsiya (shu jumladan qo’lda) va eskalatsiyalarni yozing.

26-45 kun

Avtomatlashtiring GC «osilgan» saqlar, davriy qayta ishga tushirish/davomi muddati.
O’yinni o’tkazing: qadamni rad etish, muddatdan oshib ketish, brokerning mavjud emasligi.
Voqealar shartnomalarini (versiyalar, muvofiqlik) standartlashtiring, «saqlar katalogi» ni yarating.

17) Anti-patternlar

Domenning to’g "ri teskari harakati o’rniga" kompensatsiya = DBdan delete ".
Hech qanday outbox/inbox → hodisalarni yoʻqotish/ikki marta effektlar.
Jittersiz retraylar → O’z-DDoS qaramliklari.
Oʻqishda «qayta ishlanmasdan» kuchli muvofiqlikni kutish....
Hamma narsaga bitta ulkan orkestrator → boshqaruv monolitlari.
Ko’rinmas to’liq xoreografiya va SLA → boshqarilmaydigan raqs.
Muddatlarni eʼtiborsiz qoldirish → Abadiy zaxiralar/xoldlar.

18) Etuklik metrikasi

Tanqidiy jarayonlarning 90% ≥ saga/kompensatsiya bilan qoplangan va tavsiflangan invariantlarga ega.
Outbox/inbox barcha ishlab chiqaruvchilar/konsumerlar uchun Tier-0/1.
SLO: p95 end-to-end sagi normal, success rate barqaror, orphaned <maqsadli.
Shaffof traska va dashbordlar «qadamlar bo’yicha», burn-rate alerta.
Har choraklik game-day va qo’l runbook kompensatsiyalarini tekshirish.

19) Xulosa

Saga - bu taqsimlangan tizimlar uchun amaliy muvofiqlik shartnomasi: aniq qadamlar va orqaga qaytish, nashr intizomi (outbox/inbox), muddat va retralar, kuzatuv va kompensatsiya jarayonlari. Modelni tanlang (orkestr/xoreografiya/TSS), invariantlar va kalitlarni o’rnating, qayta ishlovchilarni idempotent qiling - va sizning multiservis biznes jarayonlaringiz qimmat 2PC bo’lmasdan oldindan aytib bo’ladigan va barqaror bo’ladi.