DLQ ve zehirli mesaj işleme

Dead Letter Queue (DLQ), belirli sayıda denemeden sonra düzenli bir tüketici tarafından işlenemeyen veya bariz teknik/iş nedenleriyle (geçersiz şema, zaman aşımı, sürüm çakışması, vb.) Zehirli mesaj - yeniden işlenmesi sürekli olarak başarısız olan ve boru hattının istikrarını tehdit eden bir kayıt.

DLQ'nun amacı, SLO'yu korumak, arızayı lokalize etmek, ana akışın engellenmesini önlemek ve analiz ve güvenli tekrar (redrave) olasılığını garanti etmektir.

1) Zehirli mesajların nereden geldiği

Şemalar/sözleşmeler: uyumsuz değişiklikler, eksik gerekli alanlar, yanlış türler.
İş doğrulamaları: kopyalar, ihlal edilen değişmezler, süresi dolan olaylar.
Düzen ve nedensellik: "Oluştur'a" Güncelleme "geldi, eksik korelasyonlar, sıra dışı.
Idempotency: yeniden işleme yan etkiler yaratır.
Dış bağımlılıklar: sınırlı sınırlar/zaman aşımları, API kullanılamaması.
Veri: yük bozulması, yanlış kodlama, aşırı boyut.

2) DLQ gönderme kriterleri

• Aşıldı maxTüketici/işçide işleme girişimleri.
• Hata geri alınamaz olarak sınıflandırılır: geçersiz şema, kritik bir kaynağın olmaması, iş yasağı.
• Son tarih mesajı (TTL/expiration) sona ermiştir.
• Bu anahtar/kiracı için devre kesici veya giriş kontrol politikası tetiklendi.
• Açık operatör çözümü (ana iş parçacığından manuel "çıkarma").

3) DLQ topolojileri ve desenleri

Kuyruk başına DLQ: Her kuyruğun/konunun kendi DLQ'su vardır. Basit ve şeffaf.
Merkezi DLQ (otopark): karmaşık durumlar için genel "park", birleşik analiz araçları için uygun.
DLT (Dead Letter Topic): log yönelimli veri yolları için (olay günlüğü) - başarısızlık nedeninin meta verileriyle ayrı bir konu.
Karantina: Sert erişimli karantina tamponu ve manuel analiz için PII sanitasyonu.
Gölge akışı: Sorunlu mesajların güvenli sabitleme deneyleri için bir "gölgeye" çoğaltılması.

4) DLQ'ya eşlik etmek için gereken meta veriler

• Hata nedeni: hata kodu/sınıfı, yığın/iz kimliği.
• Bağlamı yeniden ayır: 'girişim', 'maxGirişimler','ilk _ görülen _ ts ',' son _ girişimi _ ts '.
• Korelasyon: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', bölüm anahtarı.
• Orijinal ofset/partition/sequence (log veri yolları için) veya message-id.
• Sözleşme/şema/payload sürümü.
• Idempotency-key/Request-id (varsa).
• Yönlendirme kaynağı: kuyruk adı/konu, tüketici grubu.

5) DLQ'dan önce politikaları geri çekin

• Kısa tüketici retrays: 'MaxTrials' 2-5, üstel backoff + jitter, eşzamanlılık üzerinde kapaklar.
• Kooperatif geri basınç: Hatalar büyüdükçe rekabeti azaltmak.
• Hata sınıflandırması: geri alınabilir ('5xx', timeout) vs geri alınamaz (validation, schema mismatch).
• Gecikme kuyrukları: Geçici arızalar için 5'ler - 30'lar - 2 m.
• Anahtar başına izolasyon: Belirli bir anahtar "gürültülü'ise, tüm partiyi engellemeyin.

6) Güvenli Redrive (DLQ'dan Redelivery)

Redrive, mesajların DLQ'dan işlemeye kontrollü geri dönüşüdür.

1. Düzeltme kontrolü: Yalnızca kodu/yapılandırmayı/şemayı düzelttikten sonra veya harici bağımlılıkları geri yükledikten sonra yeniden çizin.

2. Idempotency: işleyiciler tekrarlamaya karşı dirençli olmalıdır (uppert, effect-toluant işlemleri).

3. 'Idempotency _ key'/' message _ id'/' business _ key'ile veri tekilleştirme.

4. Gruplama ve pencereler: N mesajlarına göre gruplar, redrive tarafından oran sınırı, zaman/taraflara göre "pencereler".

5. Yerel doğrulama: yeniden çizmeden önce planın hızlı bir şekilde doğrulanması (erken geçersiz vakaları reddedin).

6. Öncelik: Redrive, satış trafiğini (işçilerin/bireysel havuzun düşük önceliği) değiştirmemelidir.

7. Gözlemlenebilirlik: redrive için bireysel metrikler ve yollar; Sonuç raporu (başarı/tekrar DLQ/kayıp).

7) Teslimat semantiği ve sipariş

En az bir kez en yaygın modudur: idempotence ve veri tekilleştirme gereklidir.
En fazla bir kez - DLQ devre dışı bırakılabilir; Kaybetme riski. Sadece kayıplar kabul edilebilir olduğunda kullanın.
Tam olarak bir kez (verimli): Ticari depolamada işlemler ve veri tekilleştirme ile elde edilir; pahalı ve spesifik.
Sipariş: DLQ genellikle belirli bir anahtar/parti için sırayı bozar. Sıra kritikse, anahtarla ve sırayla yeniden çizin.

8) Şemalar, sözleşmeler ve onaylama

Schema registry/contracts: clear versioning, evolution with backward/forward compatibility. - Şema kayıt defteri/sözleşmeleri: açık sürüm oluşturma, geriye/ileriye dönük uyumluluk ile evrim.
Girişte doğrulama: ağır adımlardan önce JSON Schema/Protobuf/Avro üzerinden ucuz kontrol.
Uyumsuzluk politikası: "Kırma" alanıyla - hemen DLQ'da 'SCHEMA _ UYUMSUZ' koduyla.
Redaksiyon PII: Sadece DLQ'da ihtiyacınız olanı saklayın; Hassas alanları maskeleyin.

9) Idempotency ve veri tekilleştirme

Idempotency-key: "business sense" (kiracı + varlık + operasyon + ts-bucket) gelen üretici formu.
Deadup günlükleri: son 'N' tuşlarını TTL ile saklayın; Operasyonun "etkisini" hatırlayın.
Uppert/merge: Kısıtlama olmadan "insert-only'den kaçının.
Yan etkiler: harici aramalar için - aramadan önce günlüğe kaydedin ve "tekrarlayın'ı kontrol edin.

10) Gözlemlenebilirlik ve SLO

• DLQ'da DLQ oranı (msg/s), mesajların oranı, ortalama/medyan'yaş ".
• Redrave (%) başarısı, tekrarlanan DLQ payı.
• Nedenlerin sınıflandırılması: şema, doğrulama, zaman aşımı, bağımlılık, bilinmeyen.
• P95/p99 ana tedavi gecikme vs redrive.
• DLQ boyutu, taşma riski.

• Gerekli etiketler 'message _ id', 'entity _ id', 'tenant _ id', 'entry', 'reason', 'redrive _ batch _ id'dir.
• "DLQ şubesinin" izlenmesi: kaynaktan tekrarlanan başarıya.

• Başarıyla işlenen mesajların yüzdesi T dakikalarında % X ≥.
• DLQ davası için soruşturma ve düzeltme süresi ≤ Y saat.
• DLQ ≤ Z saatlerinde mesajın maksimum'yaş'ı (uyarıyla).

11) Güvenlik ve uyumluluk

En az ayrıcalık erişimi: Redrive - yalnızca operatörler/oyun kitapları.
Denetim: Meta verileri kim ve ne zaman tetikledi/silin/düzenleyin.
Sanitasyon: Merkezi DLQ'ya transfer ederken, gereksiz PII/sırları kaldırın.
Saklama: DLQ için ayrı saklama ve silme ilkeleri.

12) Çok kiracılık

Etiketler 'tenant _ id/plan': sınırları ayırt etmek, öncelikleri yeniden yazmak, raporlar.
Kiracı başına DLQ veya taraflar: "gürültülü" istemcinin genel DLQ'yu tıkamaması için.
Faturalandırma/kotalar: DLQ hacmini ve kullanımdaki redrive maliyetini dikkate alın.

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

yaml consumer:
max_attempts: 4 backoff:
strategy: exponential_full_jitter initial_ms: 200 max_ms: 5000 classify_errors:
retryable:  [TIMEOUT, DEP_UNAVAILABLE, 5xx]
nonretryable:[SCHEMA_INCOMPATIBLE, VALIDATION_FAILED, DUPLICATE]
concurrency_caps:
per_partition: 8 per_tenant: 50

dlq:
type: topic name: myapp. events. dlq metadata:
include: [reason, stack, attempt, first_seen_ts, last_attempt_ts, schema_version,
tenant_id, entity_id, trace_id, source_topic, partition, offset]
retention_hours: 168 pii_redaction: true

redrive:
mode: batch batch_size: 500 rate_limit_per_sec: 50 priority: low validate_schema_before_redrive: true idempotency:
dedup_ttl_hours: 24 ordering:
by_key: true

14) Operasyonel oyun kitapları (runbooks)

1. Anormal DLQ büyümesi: üretim tüketicisinin kısılmasını açın, en önemli nedenleri analiz edin, sürümleri/şemaları kontrol edin.
2. Şema uyumsuzluğu: geri alma/işleme şeması, bağdaştırıcı geçişi, doğrulamadan sonra redrive.
3. Dış bağımlılık kullanılamaz: Yeniden başlatmayı duraklat, gecikme kuyruğunu etkinleştir, kurtarmadan sonra yeniden kullan.
4. Redrive'dan sonra tekrarlanan DLQ'lar: "gölge" işleyicisini/simülatörünü etkinleştirin, idempotensi kontrol edin, dar parti.
5. DLQ taşması: arşiv depolamaya tahliye, anahtarlar/nedenler için seçici redrave sağlar.

15) Test ve kaos

Hata enjeksiyonu: şema-kesme, doğrulama, zaman aşımları 1-on-N yapışkan hatalar.

Kütle revizyonu: dozajın kontrolü ve üretim üzerindeki etkisi

Sıra dışı sıra: doğru anahtar kullanımını sağlayın.
Yük bozulması: doğrulama ve güvenli arıza.
Redrive işçisinin düşüşünden sonra kurtarma: toplu işlemlerin idempotency.

16) Tipik hatalar

DLQ'da meta veri eksikliği - nedenleri kümelemek ve güvenli bir şekilde değiştirmek imkansızdır.
Sınırsız kitlesel yeniden çizim - üretimin yeniden bozulması.
Idempotency/veri tekilleştirme yok - kopyalar ve yan etkiler.
PII, sanitasyon olmadan merkezi DLQ'da karıştırılır.
Düzenlerin/sözleşmelerin eksikliği - mesajların evriminde "sürprizler".
Kiracı/anahtar bölümlemesi olmayan tek yaygın DLQ.
Geri çekilemeyen hatalar için erken DLQ yerine sonsuz retrays.

17) Hızlı tarifler

Normal iş akışı: 3-4 deneme, jitter ile üstel geri dönüş, hataların erken sınıflandırılması, tam meta verilerle DLQ.
Kritik olaylar (ödeme): sıkı idempotence, kısa zaman aşımları, minimum girişimler, hızlı DLQ ve manuel ayrıştırma.
Düzeltmeden sonra kitle yeniden çizimi: küçük partiler (100-500), oran sınırı, ayrı işçi havuzu, hızı artırmadan önce başarıyı> %95 izleme.
Çok kiracılı: kiracı başına redrive limitleri, DLQ üst müşteri jeneratör raporu.

Sonuç

DLQ bir "çöp kutusu'değil, kontrollü bir güvenilirlik döngüsüdür. Net vuruş kuralları, zengin meta veriler, idempotency ve veri tekilleştirme, güvenli ölçülü redrive, şema disiplini ve gözlemlenebilirlik, toksik mesajları bir tehditten SLO'ya yönetilebilir bir mühendislik sürecine dönüştürür - anlaşılır oyun kitapları, öngörülebilir maliyetler ve kullanıcılar üzerinde minimum etki.