Saga deseni ve dağıtılmış işlemler

Saga modeli ve dağıtılmış işlemler

1) Destanlara neden ihtiyaç duyulur

Klasik 2PC (iki fazlı mandallama) zayıf ölçeklenebilir, arızalar altında karmaşıktır ve kaynakları engeller. Destan, genel iş sürecini, her biri bağımsız olarak taahhüt eden bir dizi yerel işleme (adım) ayırır. Arıza durumunda, sonraki adımlar iptal edilir ve tamamlanmış olanlar ters işlemlerle telafi edilir.
Sonuç: küresel engelleme olmadan yönetilen nihai tutarlılık, yüksek beka ve net bir kurtarma protokolü.

2) Temel modeller

2. 1 Orkestrasyon

Özel bir destan koordinatörü adımları yönetir: komutlar gönderir, yanıtları/olayları bekler, telafileri başlatır.
Artıları: merkezi kontrol, basit gözlemlenebilirlik, açık son tarihler. Eksileri: İsteğe bağlı bileşen.

2. 2 Koreografi

Koordinatör yok; Servisler birbirlerinin etkinliklerine yanıt verir ("OrderPlaced -" "PaymentCaptured" - "InventoryReserved...").
Artılar: Zayıf bağlantı. Eksileri: takip etmek daha zor, açık kurallar olmadan "ölüm dansı" riski.

2. 3 TTK (Try-Confirm/İptal)

1. Dene - hazırlık/rezerv,

2. Onayla - sabitleme,

3. İptal - geri alma.

Garantiler daha yüksektir, ancak sözleşmeler ve yedek süreler daha karmaşıktır.

3) Adım ve tazminat sözleşmeleri

Her adım = yerel işlem + tazminat (idempotent, tekrarlamaya izin verir).
Tam olarak "dünyayı iade etmek" için tazminat gerekmez - alan eşdeğerliği yeterlidir (örneğin, "ödemeyi silmek" yerine "iade ödemesi").
Değişmezleri tanımlayın: para için - denge eksiye girmez; emirler için - "asılı" durum yok.
Son tarihler/TTL rezervleri ve gecikmiş girişimler için bir "çöp toplayıcı" girin.

4) Tutarlılık ve teslimat semantiği

İleti teslimi: En az bir kez (varsayılan) - tüm işlemler idempotent olmalıdır.
Sıra: korelasyon anahtarı ile önemli (örn. 'order _ id', 'player _ id').
Tam olarak-bir kez destanın amacı değil; idempotent anahtarlar, giden/gelen kutusu ve doğru taahhüt yoluyla etkili bir tekdüzelik elde ediyoruz.

5) Destanın durumu ve günlüğü

• 'saga _ id', 'correlation _ id', geçerli durum (Running/Completed/Compensating/Compensated/Failed),
• adım ve değişkenleri (ödeme/rezerv kimlikleri),
• Olayların/kararların tarihi (günlüğü), zaman damgaları, son tarihler, geri alma sayısı.

• Koordinatörün kullanabileceği ayrı bir Saga Mağazası (tablo/belge).
• Koreografi için - destanın yerel "ajanları", ortak bir konuda durum olayları yayınlamak.

6) Güvenilir yayınlama kalıpları: giden kutusu/gelen kutusu

Giden kutusu: adım değişikliği taahhüt eder ve olayı/komutu bir işlemde giden kutusu tablosuna yazar; İşçi lastiğe yayın yapar.
Gelen kutusu: tüketici işlenmiş bir 'message _ id' tablosunu tutar - dedup + idempotency.
Başarılı bir yan etkiden sonra ofset/ACK (Kafka/RabbitMQ) uygulayın - daha önce değil.

7) Destan adımlarını tasarlama

7. 1 Örnek (iGaming/e-ticaret satın alma)

1. PlaceOrder - durum 'BEKLEMEDE'.
2. AuthorizedPayment (Try) - 'payment _ hold _ id'.
3. ReserveInventory - 'reservation _ id'.
4. CapturePayment (Onayla).
5. FinalizeOrder - 'Tamamlandı'.

• (3) 'CancelPaymentHold' başarısız olursa;
• (4) sonra başarısız (3) - 'ReleaseInventory';
• (5) "Geri Ödeme've" ReleaseInventory "başarısız olursa.

7. 2 Son Tarihler/Geri Çekilmeler

Üstel gecikme + jitter ile maksimum N retrays.
Aştıktan sonra - 'Telafi etme'ye gidin.
Her adım için next_attempt_at ve deadline_at saklayın.

8) Orkestratör vs platform

• Hafif ev orkestratörü (microservice + Saga tablosu).
• Platformlar: Temporal/Cadence, Camunda, Netflix Conductor, Zeebe - zamanlayıcılar, retrays, uzun ömürlü iş akışları, görünürlük ve bir web konsolu verin.
• Koreografi için bir etkinlik kataloğu ve sıkı bir durum/anahtar kuralı kullanın.

9) Entegrasyon protokolleri

9. 1 Asenkron (Kafka/RabbitMQ)

Komutlar: 'ödemeler. yetkilendirin. v1 ',' envanter. rezerv. v1 '.
Olaylar: 'ödemeler. yetkilendirildi. v1 ',' envanter. ayrılmış. v1 ',' ödemeler. yakalandı. v1 ',' ödemeler. İade edildi. v1 '.
Parça anahtarı = sipariş için 'order _ id'/' player _ id'.

9. 2 Bir adımda senkron (HTTP/gRPC)

"Kısa" adımlar için geçerlidir, ancak her zaman zaman aşımı/geri ödeme/idempotency ve asenkron telafiye geri dönüş ile.

10) Idempotence ve anahtarlar

Komut ve tazminat taleplerinde, 'idempotency _ key' iletin.
Yan etkiler (veritabanına yazma/kapatma) koşullu olarak gerçekleştirilir: "henüz 'idempotency _ key' görmediyseniz gerçekleştirin".
Tazminat da idempotent: 'ReturnPayment (id = X)' tekrarlanması güvenlidir.

11) Hata işleme

• Geçici (ağlar/zaman aşımları) - geri alma/geri alma.
• İş (yetersiz fon, limitler) - acil tazminat/alternatif yol.
• Geri alınamaz - manuel müdahale, manuel telafi.
• Bir çözüm matrisi oluşturun: hata türü - eylem (yeniden deneyin/telafi edin/artırın).

12) Gözlemlenebilirlik ve SLO sarkması

• Destanın uçtan uca gecikme süresi (p50/p95/p99).
• Başarı oranı.
• Telafi etmek için ortalama zaman и tazminat oranı.
• Yetim sagalar ve GC'ye zaman.
• Trace: Adımlar arasında yayılma bağlantısı olarak 'trace _ id'/' saga _ id'; Hata bütçeleri için yazma oranı metrikleri.

Günlükler: Her saga durum değişikliği = nedeni ile yapılandırılmış kayıt.

13) Örnekler (pseudocode)

13. 1 Orkestratör (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 Çıkış Kutusu (tablo fikri)

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 Koreografi (tema fikirleri)

'emirler. Yerleştirilmiş '- tüketiciler: ' ödemeler. Yetki ',' envanter. Rezerv '

'ödemeler. Yetkili '+' envanter. Ayrılmış '-' emirler. try_finalize'

Emirler herhangi bir başarısızlık. Tazminat '- başlatılan' ödemeler. İptal/geri ödeme ',' envanter. Serbest bırakın '.

14) 2PC ve ES ile karşılaştırma

2PC: güçlü tutarlılık, ancak tıkanmalar, darboğazlar, bakır borular.
Saga: nihai tutarlılık, telafi ve telemetri disiplinine ihtiyacınız var.
Olay Kaynağı: olayları bir hakikat kaynağı olarak depolar; Üzerindeki destanlar doğaldır, ancak göçlere/anlık görüntülere karmaşıklık katar.

15) Güvenlik ve uyumluluk

Taşıma güvenliği (TLS/mTLS), konu/kuyruk başına ACL.
Olaylarda - en azından PII, hassas alanların şifrelenmesi, tokenization.
Sagalara ve tazminat günlüklerine erişimi denetleyin.
Dış sağlayıcılarla SLA (ödemeler/teslimat) = son tarih ve yeniden ödeme sınırı parametreleri.

16) Uygulama kontrol listesi (0-45 gün)

0-10 gün

Aday süreçleri seçin (çoklu hizmet, telafi).
Modeli (orkestrasyon/koreografi/TCC) ve korelasyon anahtarını seçin.
Adımları/ofsetleri, değişmezleri ve son tarihleri tanımlayın. 'saga', 'giden kutusu', 'gelen kutusu' tablolarını yükseltin.

11-25 gün

Giden kutusu/gelen kutusu, idempotency ve backoff retraces içerir.
Deploite ilk sagas; SLI/SLO panoları ve izleme ekleyin.
Tazminatlar (manuel dahil) ve yükselmeler için bir çalışma kitabı yazın.

26-45 gün

GC "asılı" sagaları otomatikleştirin, son teslim tarihinde periyodik yeniden başlatmalar/devam ettirmeler.
Oyun gününü geçirin: adım hatası, son tarih fazlalığı, komisyoncu bulunamazlığı.
Olay sözleşmelerini standartlaştırın (sürümler, uyumluluk), bir "saga dizini" oluşturun.

17) Anti-desenler

Etki alanı düzeltmeli ters eylem yerine "Compensation = delete from database".
Giden kutusu/gelen kutusu yok - olay kaybı/çift etki.
Jitter olmadan Retrai - kendi kendine DDoS bağımlılıkları.
"İşleme devam etmeden" okuma konusunda güçlü tutarlılık beklemek....
Herkes için dev bir orkestratör - kontrol monoliti.
Görünürlük ve SLA olmadan toplam koreografi - kontrol edilemeyen dans.
Son teslim tarihlerini görmezden gelmek - ebedi rezervler/tutar.

18) Vade metrikleri

Kritik süreçlerin ≥ %90'ı sagalar/telafiler tarafından kapsanır ve tanımlanan değişmezlere sahiptir.
Giden kutusu/gelen kutusu tüm Tier-0/1 üreticileri/tüketicileri için entegre edilmiştir.
SLO: p95 uçtan uca destan normal, başarı oranı istikrarlı, yetim <hedef.
Şeffaf izleme ve gösterge panoları "adımlarda", yanma oranı uyarıları.
Üç aylık oyun günü ve manuel çalışma kitabı tazminat kontrolü.

19) Sonuç

Saga, dağıtılmış sistemler için pratik bir tutarlılık sözleşmesidir: açık adımlar ve ters eylemler, yayın disiplini (giden kutusu/gelen kutusu), son tarihler ve geri ödemeler, gözlemlenebilirlik ve telafi süreçleri. Bir model seçin (orkestrasyon/koreografi/TSS), değişmezleri ve tuşları düzeltin, işleyicileri idempotent yapın - ve çok servisli iş süreçleriniz pahalı 2PC olmadan öngörülebilir ve istikrarlı hale gelecektir.