GH GambleHub

Dastanlar və paylanmış əməliyyatlar

Saga müxtəlif xidmətlərdə/anbarlarda lokal addımların ardıcıllığına bölünmüş uzunmüddətli biznes əməliyyatıdır. Hər addım qismən uğursuzluqla addım təsirini geri qaytaran kompensasiya effektinə malikdir. 2PC/3PC fərqli olaraq, dastanlar qlobal kilidləri tutmur və eventual consistency üçün icazə verilən mikroservislər, çox bölgələr və yüksək yüklər üçün uyğundur.


1) Nə zaman dastan seçmək (və nə zaman - deyil)

Uyğun:
  • Uzun/çox mərhələli biznes prosesləri (sifariş → ödəniş → ehtiyat → çatdırılma).
  • Ümumi əməliyyatın olmadığı müxtəlif domenlər və anbarlar.
  • Yüksək mövcudluq və üfüqi miqyas tələb olunur.
Uyğun deyil:
  • Qatı ACID-atom əhəmiyyətlidir (məsələn, bir reyestr daxilində böyük məbləğlərin köçürülməsi).
  • Aydın kompensasiya yoxdur («rezerv» və ya təsiri ləğv edilə bilməz).
  • Hüquqi/tənzimləyici məhdudiyyətlər ciddi təcrid və «ani» invariant tələb edir.

2) Saqa modelləri

1. Orkestr (Saga Orchestrator): Mərkəzi koordinator addımları və kompensasiyaları idarə edir.

Üstünlüklər: aydın axın, səhv nəzarəti, sadələşdirilmiş telemetri.
Mənfi cəhətləri: mərkəzləşdirmə nöqtəsi, «qalın» koordinator riski.

2. Xoreoqrafiya (Choreography): heç bir mərkəz - addımlar hadisələrlə başlanır («Xidmət etdi X → xidmət B cavab verir»).

Üstünlüklər: zəif bağlılıq, sadə miqyas.
Mənfi cəhətləri: axını izləmək/debaj etmək daha çətindir, qaydaların «böyüməsi» riski.

3. TCC (Try-Confirm/Cancel): Hər addım - «rezervasiya» (Try), sonra təsdiq (Confirm) və ya ləğv (Cancel).

Üstünlüklər: psevdo-iki fazalı protokola daha yaxın, idarə olunan resurslar.
Mənfi cəhətləri: interfeyslərin həyata keçirilməsində daha bahalı; «Try» sahiblərinin vaxtını tələb edir.


3) Addım və kompensasiya layihələndirilməsi

İnvariantlar: addımdan əvvəl/sonra (məsələn, «0 ≥ qalıq») doğru olan şeyi dəqiq ifadə edin.
Kompensasiya ≠ əks əməliyyat: bu, iş effektini ləğv edən məntiqi hərəkətdir (refund, release, bərpa).
İdempotentlik: həm addım, həm də kompensator təhlükəsiz şəkildə təkrarlanmalıdır ('operation _ id' ilə).
Zaman: hər addım deadline var; gecikmə kompensasiya təşəbbüsü.
Geri qaytarılmayan effektlər: onları ayrıca qeyd edin (bildirişlər, e-mail) və "ən yaxşı effort 'a icazə verin.


4) Uyğunluq və nizam

Eventual consistency: istifadəçilər müvəqqəti uyğunsuzluqları görə bilər; UX - «gözləmə «/spinner/statusları ilə.
Açar qaydası: kommutasiya addımlarını biznes açarı ilə qruplaşdırın (hadisələri nizamlamaq üçün order_id).
Deduplikasiya: TTL ilə müalicə jurnalını ('operation _ id' → status) saxlayın.


5) Nəqliyyat və etibarlılıq

Outbox pattern: Eyni əməliyyat daxilində yerli «outbox» cədvəlinə hadisəni yazmaq və sonra şinə asenxron nəşr.
Inbox/Idempotency store: istehlakçı tərəfində - artıq emal edilmiş mesajların jurnalı.
Exactly-once effektiv: «outbox + idempotent consumer» praktik verir «düz bir dəfə».
DLQ: zəngin meta məlumat və təhlükəsiz redrayv ilə «zəhərli» mesajlar üçün.


6) Səhv siyasəti, retraj, backoff

Yalnız idempotent addımları təkrarlayın; əməliyyat qeyd - ilə 'Idempotency-Key'.
Eksponent backoff + jitter; cəhdlərin məhdudlaşdırılması və dastanın ümumi müddəti.
Sistemli deqradasiya zamanı - Circuit Breaker və graceful degradation (məsələn, dastanın ikinci dərəcəli fiqa hissəsini ləğv etmək).
Biznes münaqişələri ('409') - razılaşdırıldıqdan sonra təkrar və ya kompensasiya və tamamlamaq.


7) Orkestrator: vəzifələr və struktur

Funksiyalar:
  • Dastanın vəziyyətinin izlənməsi: 'PENDING → RUNNING → COMPENSATING → DONE/FAILED'.
  • Addımların, müddətlərin, vaxtların, retrajların planlaşdırılması.
  • Tədbirlərin marşrutlaşdırılması və kompensasiyanın başlaması.
  • Koordinator əməliyyatlarının idempotentliyi (komanda jurnalı).
  • Müşahidə: log/trace/metriklərdə 'saga _ id' korrelyasiyası.
Saxlama:
  • Cədvəllər 'saga', 'saga _ step', 'commands', 'outbox'.
  • «saga _ id», «business _ key», «status», «next _ run _ at» üzrə indekslər.

8) Xoreoqrafiya: qaydalar və "qartopu 'ndan qorunma

Hadisə müqavilələri: sxemlər və versiyalaşdırma (Avro/Proto/JSON Schema).
Aydın semantika: «fakt hadisəsi» vs «komanda».
Zəncirin dayandırılması: xidmət uyğunsuzluq aşkar edərək «Failed »/« Compensate» hadisəsini dərc edir.
Siqnalizasiya və «sonsuz döngələr» üçün alertlər.


9) TCC: praktik detallar

Try: TTL ilə resurs ehtiyatı.
Confirm: fiksasiya, müvəqqəti kilidlərin azad edilməsi.
Cancel: ehtiyat geri çəkilməsi (yan təsirləri olmadan).
Garbage collection: TTL (İdempotent Cancel) sonra avtomatik geri qaytarılması Try.
İdempotent Confirm/Cancel: təkrar təhlükəsiz.


10) Nümunə (şifahi sxem) - «Ödəniş və çatdırılma ilə sifariş»

1. CreateOrder (yerli) → outbox: 'OrderCreated'.
2. PaymentService: ehtiyat 'Try' (TCC); → 'PaymentReserved' müvəffəqiyyətli olduqda, → 'PaymentFailed' uğursuz olduqda.
3. InventoryService: əmtəə ehtiyatı; → 'InventoryFailed' çatışmazlığı ilə.
4. ShippingService: çatdırılma yuvası yaratmaq (ləğv).
5. Hər hansı bir addım 'Failed' → orkestrator kompensasiyanı tərs qaydada işə salır: 'CancelShipping' → 'ReleaseInventory' → 'PaymentCancel'.
6. Hər şey yaxşıdırsa → 'PaymentConfirm' → 'OrderConfirmed'.


11) Orkestratorun psevdokodu

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) Müşahidə və əməliyyat SLO

Trace: vahid 'saga _ id', 'step', 'attempt', 'decision' (run/compensate/skip) şərhləri.

Metriklər:
  • Uğur/saq səhv (%), orta müddət, p95/p99.
  • Kompensasiya edilmiş saqların payı, kompensasiyanın ən yaxşı səbəbləri.
  • Növbələr/outbox lag, addım retras.
  • Log/audit: orkestrator həlləri, resurs identifikatorları, biznes açarları.

13) Test və xaos

Hər addımda səhvlərin inyeksiyası: taymaut, '5xx', biznes münaqişələri.
Out-of-order hadisələr, dublikatlar, pass (drop).
Uzun gecikmə quyruqları → son tarixlərin və kompensasiyaların yoxlanılması.
Kütləvi dastanlar → WFQ/DRR və caps-in yoxlanılması, heç bir «head-of-line blocking».
Addımlarla və bütün dastanla DLQ-dən Redrave.


14) Multi-tenant, regionlar, uyğunluq

'tenant _ id/plan/region' tədbirlərdə və saqların anbarlarında.
Residency: məlumat/hadisələr bölgəni tərk etmir; cross-regional dastanlar yerli saqalar federasiyası + yığma hadisələr kimi dizayn.
Prioritetləşdirmə: VIP dastanları daha böyük kvota çəkisinə malikdir; per tenant oxu izolyasiya.


15) Satış öncəsi yoxlama siyahısı

  • Hər addımda aydın bir kompensator var, hər ikisi də idempotentdir.
  • Seçilmiş şablon: orkestr/xoreoqrafiya/TSS; məsuliyyət sərhədləri təsvir edilmişdir.
  • Outbox/Inbox tətbiq, 'operation _ id' deduplication.
  • Retraj siyasətləri: jitter ilə backoff, cəhd limitləri və ümumi son tarix dastanları.
  • Hadisə müqavilələri version, sxem validasiya var.
  • DLQ və təhlükəsiz redrave özelleştirilmiş.
  • Telemetriya: metrika, treysinq, korrelyasiya 'saga _ id'.
  • Əməliyyat playbooks: əl cancel/force-confirm, «asılmış» saqlar.
  • Xaos və yük testləri keçir, SLO/səhv büdcəsi müəyyən edilir.

16) Tipik səhvlər

Kompensator yoxdur və ya «murdar» (yan təsirləri var).
İdempotentlik/dedup yoxdur - ikiqat və «yelləncək» halları.
«Dastanda dastan» heç bir sərhədsiz - dövrlər və qarşılıqlı kilidlər.
Heç bir müddət → «əbədi» dastanlar və resursların sızması.
Orkestrator sabit stor olmadan «yaddaşda» saxlayır.
Telemetriya mərkəzi olmadan xoreoqrafiya → «görünməz» uğursuzluqlar.
Qeyri-şəffaf UX: istifadəçilər ara statusları görmürlər.


17) Sürətli reseptlər

SaaS klassikası: orkestrasiya + outbox/inbox, eksponensial backoff, DLQ, dastan statusları UI.
Resurs üçün güclü invariantlar: TTL ehtiyat və GC Cancel ilə TCC.
Yüksək həcm/yük: hadisələrin xoreoqrafiyası + ciddi idempotentlik və açar metrikası.
Multi-region: yerli dastanlar + son aqreqatlar; qlobal kilidlərdən qaçın.


Nəticə

Dastanlar qlobal bloklar olmadan paylanmış sistemlərdə proqnozlaşdırıla bilən uyğunluq əldə etmək üçün bir yoldur. Aydın kompensatorlar, idempotentlik, etibarlı çatdırılma (outbox/inbox), zaman və retraut nizam-intizamı, üstəgəl telemetriya və playbook - mürəkkəb iş proseslərinin yükün, xidmətlərin və coğrafiyanın artması ilə sabit və oxunaqlı qalmasının açarı.

Contact

Bizimlə əlaqə

Hər hansı sualınız və ya dəstək ehtiyacınız varsa — bizimlə əlaqə saxlayın.Həmişə köməyə hazırıq!

İnteqrasiyaya başla

Email — məcburidir. Telegram və ya WhatsApp — istəyə bağlıdır.

Adınız istəyə bağlı
Email istəyə bağlı
Mövzu istəyə bağlı
Mesaj istəyə bağlı
Telegram istəyə bağlı
@
Əgər Telegram daxil etsəniz — Email ilə yanaşı orada da cavab verəcəyik.
WhatsApp istəyə bağlı
Format: ölkə kodu + nömrə (məsələn, +994XXXXXXXXX).

Düyməyə basmaqla məlumatların işlənməsinə razılıq vermiş olursunuz.