İşlemsel Mesajlaşma

İşlemsel mesajlaşma, yerel durum değişiklikleri (veritabanı/önbellek) ile broker/bus üzerindeki mesajlar arasında tutarlılık sağlayan bir dizi mimari tekniktir. Amaç: Arıza, geri alma, ölçeklendirme ve çoklu kiracılık durumunda "durum sabittir ↔ mesaj kaybolmaz veya çoğaltılmaz".

1) Teslimat semantiği

En çok bir kez: Hızlı ve ucuz, kayıplar mümkün, almak yok.
En az bir kez: mesajları kaybetmez, kopyalar mümkündür - idempotency gereklidir.
(Etkili) Tam olarak bir kez: Tekniklerin bir kombinasyonu (giden kutusu/gelen kutusu, üretici/tüketici işlemleri, dedup) ile elde edilen iş etkileri için kayıp ve görünür bir şey yok.

2) Neden "iki harfli" tehlikelidir

Naif mantık'önce veritabanına yaz, sonra veri yoluna gönder "(veya tam tersi) adımlar arasında düşerken kırılır: veriler sabittir ve olay kaybolur; Ya olay gitti, ama veri yok. İşlemsel mesajlaşma bu boşluğu kapatır.

3) Temel desenler

3. 1 Çıkış kutusu (üretici)

Bir yerel işlemde, iş değişikliğini ve satırı 'giden kutusu' tablosuna yazarız; Ayrı bir yayıncı giden kutusunu okur ve retras ve backoff ile bir komisyoncuda yayınlar. Hariç tutulan kayıplar; çiftler tüketiciler arasında idempotency tarafından söndürülür.

3. 2 Gelen Kutusu/Idempotent Tüketici

Efekti çalıştırmadan önce, tüketici birincil anahtar olarak 'gelen kutusunda (tüketici, event_id)' INSERT 'yapar. Key conflict = event already processed - skip. Bu şekilde "etkili bir şekilde tam olarak bir kez" elde edilir.

3. Ofset İşlemle 3 Okuma-İşlem-Yazma

Günlük odaklı otobüsler için şablon: Tüketici partiyi okur, aynı işlemde iş değişikliğini ve "geçti ofsetini kaydeder. "Taahhütten sonra, komisyoncu tüketilen mesajları dikkate alır. Bu, efektte kopyalar olmadan "oku - düşüş - tekrarlama'yı ortadan kaldırır.

3. Servisler arası efektler için 4 TSS/Saga

Tutarlı çok adımlı bir sürece ihtiyacınız olduğunda, TTK veya destanları kullanın; Mesajlar - komutların/olayların taşınması ve işlemsellik - adımlar ve tazminatlar düzeyinde.

4) Idempotent üreticileri ve tüketicileri

Producer: Stabil 'message _ id'/' idempotency _ key', aynı anahtarla yeniden göndermek aboneler için yeni etkiler yaratmaz; Sırayı tuşla koru.
Tüketici: 'Gelen kutusu' + iş idempotency (upsert/merge, check latest version/revision).

5) Düzen ve nedensellik

Bir nesnenin olaylarının sırayla gelmesi için iş anahtarına (örneğin, 'aggregate _ id', 'tenant _ id') katılın.
Lot içinde ardışık sayılar/zaman damgaları tutun; DLQ'dan yeniden çizerken, "anahtarla ve sırayla" gözlemleyin.
Küresel düzen kritik değilse, yerel düzeni anahtarla sağlayın ve etki alanı değişmezlerini düzeltin.

6) Ofsetler ve sabitleme efektleri

Seçenek A: "DB'de ofset"

Etki alanı verilerini değiştirdiğiniz aynı işleme "last processed offset (partition, offset)" yazın. Yeniden başlatırken, tekrarlanan bir etkiden kaçınarak bir sonraki kenardan devam edin.

Seçenek B: Broker İşlemi

Bazı brokerler, bir üretici/tüketici işleminde mesajların ve ofsetlerin atomik kaydını destekler. Varsa kullanın, ancak her zaman tüketici üzerinde idempotency ile tamamlayın.

7) Retrai, geri alma, DLQ

Yalnızca geri alınabilir hataları (zaman aşımları, 5xx), üstel geri alma ve jitter ile tekrarlayın.
Geri alınamaz (şema/doğrulama) - hemen DLQ'da meta verilerle (kiracı, anahtar, ofset, sebep).
Redrave'i DLQ'dan (toplu, oran limiti) dozlayın, tekrarlamadan önce devreyi kontrol edin, siparişi anahtarla izleyin.

8) Çok kiracılık ve bölgeler

Mesaj meta verilerine ve bölüm anahtarlarına 'tenant _ id', 'plan', 'bölge' ekleyin.
Kiracı başına adalet: "Gürültülü" müşterinin bütçeyi geri kalanından düşmemesi için yayınlamayı/işlemeyi sınırlayın.
Yerleşim: Mesajları ve giden kutusunu etki alanı verileriyle aynı bölgede saklamak; Bölgeler arası replikasyonlar - asenkron agregalar.

9) Gözlemlenebilirlik ve denetim

İzleme: korelasyon 'event _ id'/' aggregate _ id'/' saga _ id', "oku _ süreç - yaz/işlet".
Metrikler: yayınlama/işleme gecikmesi (p95/p99), başarı oranı, DLQ oranı, redrive başarısı, "kopyalar bastırıldı".
Günlükler: başarının kısaltması; Hatalarla ilgili ayrıntılar (sebep, deneme, anahtar, ofset).
Denetim: Kim yeniden çizdi/geri aldı, hangi parti ve hangi sonuçla.

10) Güvenlik ve uyumluluk

Yükte PII'yi en aza indirin; DLQ/günlüklere aktarırken maske.
Harici veri yolları için mesajları imzalayın/şifreleyin; Hizmetler arasında mTLS kullanın.
Raf ömrünü ve kiracı/bölge başına "unutma hakkını" yönetin.

11) Tipik entegrasyon şemaları

1. Servis kaynağı (yazma tarafı)

Yerel işlem: etki alanı kaydı + giden kutusu.
Yayıncı: gruplar, 'SKIP LOCKED', backoff, kiracı başına limitler.
Lag 'now − occurred_at' izleniyor.

2. Hizmet-tüketici (okuma tarafı)

Toplu okuma - 'INSERT gelen kutusu (tüketici, event_id)' deneniyor - başarılı olursa, efekti yürütüyoruz.
Aynı işlemde, "geçiş ofsetini" (A seçeneği) düzeltiriz veya brokerin işlemine güveniriz (B seçeneği).
Hata: Politikaya göre yeniden ödeme veya DLQ.

3. Projeksiyon/materyalize görünüm

Yalnızca idempotent güncelleştirmeleri (upsert), kompakt veri tekilleştirme anahtarları, periyodik sağlama toplamı doğrulaması.

12) Yapılandırma şablonları (örnek)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Satış öncesi kontrol listesi

• "iki harfli" elendi: Üreticiye giden kutu veya tüketicideki bir işlemde ofset ve etkinin sabitlenmesi.
• Idempotent tüketici: 'Gelen kutusu'/dedup dergi, operasyonların iş idempotency.
• İşletme anahtarına göre bölümleme, yerel sipariş takip edilir.
• Backoff + jitter retraces, hata sınıflandırması, meta veri açısından zengin DLQ.
• Redrave dozlanmış, güvenli; Oyun kitapları var.
• Çok kiracılı sınırlar ve öncelikler; 'tenant _ id/plan/region' etiketleri.
• Telemetri: gecikmeler, başarı oranı, "kopyalar bastırıldı", p95/p99 ile uyarılar.
• PII/saklama/şifreleme politikaları uygulanır.
• Testler: adımlar arasında düşüş, kopyalar, anahtar sırası, kitle yeniden çizimi.

14) Tipik hatalar

Veri yoluna gönderme ve veri tabanına ayrı adımlarla, giden kutusu/ofset işlemi olmadan yazma.
Idempotency olmayan bir tüketici - yan etkileri çoğaltır.
"Ne olursa olsun" küresel düzeni pahalı ve nadiren haklı; Anahtarla yeterli sipariş.
Sınırsız büyük bir yeniden çizim - ikincil bir olay.
İzleme/gecikme metriklerinin eksikliği - "gizli bozulma".
DLQ/günlüklerde PII karıştırma.

15) Hızlı tarifler

SaaS olayları: Outbox + idempotent consumer (gelen kutusu), 'tenant _ id: aggregate _ id'ile bölümleme.
ETL/projeksiyonlar: Bir işlemde ofset sabitleme ile okuma-süreç-yazma, toplu 500-1000, upsert.
Yüksek yük: Yayın parçaları, 'SKIP LOCKED', kiracı başına WFQ, gecikme kontrolü.
Sıkı uyumluluk bölgesi: bölgesel giden kutusu, yük şifreleme, redrives tutma ve denetim.

Sonuç

İşlemsel mesajlaşma, verileri ve mesajları bağlama disiplinidir. Giden kutusu/gelen kutusu, idempotency, ofset fiksasyonunu efektlerle ve yönetilen DLQ ile birlikte birleştirerek, global kilitler olmadan tam olarak bir kez pratik davranışlar elde edersiniz ve çökmeler, tepe noktaları ve karmaşık çok kiracılı sömürü ile bile SLO'yu korursunuz.