DLQ și manipularea mesajelor otrăvitoare

Dead Letter Queue (DLQ) este o coadă izolată/subiect pentru mesajele care nu au putut fi procesate de un consumator obișnuit după un anumit număr de încercări sau din motive tehnice/de afaceri evidente (schemă invalidă, timeout, conflict de versiune etc.). Mesaj otravă - o înregistrare a cărei reprocesare eșuează în mod constant și amenință stabilitatea conductei.

Scopul DLQ este de a păstra SLO, localiza eșecul, preveni blocarea fluxului principal și de a garanta posibilitatea de analiză și reluare în condiții de siguranță (redrave).

1) În cazul în care mesajele otrăvitoare provin de la

Scheme/contracte: modificări incompatibile, câmpuri obligatorii lipsă, tipuri incorecte.
Validări de afaceri: duplicate, invariante încălcate, evenimente expirate.
Ordine și cauzalitate: a venit „Actualizare” la „Creare”, corelații lipsă, out-of-order.
Idempotență: reprocesarea generează efecte secundare.
Dependențe externe: limite/termene limitate, indisponibilitate API.
Date: corupția sarcinii utile, codificarea incorectă, supradimensionarea.

2) Criterii de depunere DLQ

• Depășit maxÎncercări de prelucrare la consumator/lucrător.
• Eroarea este clasificată ca neretrizabilă: schema invalidă, lipsa unei resurse critice, interdicția de afaceri.
• Mesajul limită (TTL/expirare) a expirat.
• Întrerupătorul de circuit sau politica de control al admiterii a fost declanșată pentru această cheie/chiriaș.
• Soluție operator explicită (manual „eject” din firul principal).

3) Topologii și modele DLQ

Per-coadă DLQ: fiecare coadă/subiect are propriul DLQ. Simplu și transparent.
DLQ central (parcare): „parcare” generală pentru cazuri complexe, convenabilă pentru instrumente de analiză unificate.
DLT (Dead Letter Topic): pentru autobuze orientate spre jurnal (event log) - un subiect separat cu metadate ale motivului eșecului.
Carantină: tampon de carantină cu acces greu și salubritate PII pentru analiză manuală.
Shadow-stream: Duplicarea mesajelor problematice într-o „umbră” pentru experimente de fixare securizate.

4) Metadate necesare pentru a însoți DLQ

• Motivul eșecului: cod de eroare/clasă, id stivă/urmă.
• Retray context: 'încercare', 'maxÎncercări', 'first _ seen _ ts',' last _ încercare _ ts'.
• Corespondență: 'trace _ id',' span _ id', 'tenant _ id',' entity _ id', cheia de partiție.
• Decalaj original/partiție/secvență (pentru autobuze jurnal) sau mesaj-id.
• Versiune contract/schema/sarcina utila.
• Idempotency-key/Request-id (dacă există).
• Sursă de rutare: nume/subiect de coadă, grup de consumatori.

5) Politicile de retractare înainte de DLQ

• Returnări scurte de consum: „maxÎncercări” 2-5, backoff exponențial + jitter, capace pe concurență.
• Backpressure cooperativ: Reducerea concurenței pe măsură ce erorile cresc.
• Clasificarea erorilor: retractabilă ('5xx', timeout) vs neretrizabilă (validare, neconcordanță schemă).
• Cozi de întârziere: 5s → 30s → 2m pentru eșecuri temporare.
• Izolarea la cheie: dacă o anumită cheie este „zgomotoasă”, nu blocați întreaga parte.

6) Redrive în condiții de siguranță (Redelivery from DLQ)

Redrive este returnarea controlată a mesajelor de la DLQ la procesare.

1. Verificați fix: redesenați numai după fixarea codului/configurației/schemei sau după restaurarea dependențelor externe.

2. Idempotență: agenții de manipulare trebuie să fie rezistenți la repetiție (operații upsert, cu efect toluant).

3. Deduplicarea prin 'idempotency _ key '/' message _ id'/' business _ key'.

4. Batching și ferestre: loturi de mesaje N, rata-limită de redrive, „ferestre” de timp/părți.

5. Validarea locală: verificarea rapidă a schemei înainte de redesenare (respingerea cazurilor invalide timpurii).

6. Prioritate: Redrive-ul nu ar trebui să deplaseze traficul de vânzări (prioritate scăzută a lucrătorilor/grup individual).

7. Observabilitate: măsurători individuale și trasee pentru redrive; raport rezultat (succes/repetare DLQ/pierdere).

7) Semantica de livrare și comanda

Cel puțin o dată este cel mai comun mod: sunt necesare idempotență și eliminare a duplicatelor.
At-most-once - DLQ poate fi dezactivat; risc de pierdere. Utilizați numai atunci când pierderile sunt acceptabile.
Exact o dată (eficient): realizat prin tranzacții și eliminarea duplicatelor în stocarea de afaceri; scump și specific.
Comanda: DLQ rupe de obicei comanda pentru o anumită cheie/parte. Dacă ordinea este critică, redesenați prin cheie și secvențial.

8) Scheme, contracte și validare

Registru schemă/contracte: versiuni clare, evoluție cu compatibilitate înapoi/înainte.
Validarea la intrare: verificați ieftin prin JSON Schema/Protobuf/Avro înainte de pași grei.
Politica de incompatibilitate: cu un câmp de „rupere” - imediat în DLQ cu codul „SCHEMA _ INCOMPATIBIL”.
PII de redacție: Stocați numai ceea ce aveți nevoie în DLQ; masca câmpuri sensibile.

9) Idempotență și deduplicare

Idempotency-key: formularul producătorului din „business sense” (chiriaș + entitate + operare + ts-bucket).
Jurnalele deadup: păstrați ultimele chei „N” cu TTL; amintiți-vă „efectul” operațiunii.
Upsert/fuziune: Evitați „insert-only” fără restricții.
Efecte secundare: pentru apeluri externe - jurnal și verificați „repetați” înainte de a apela.

10) Observabilitate și SLO

• Rata DLQ (msg/s), proporţia mesajelor, media/vârsta mediană în DLQ.
• Succesul redrave (%), cota DLQ repetată.
• Clasificarea cauzelor: schemă, validare, timeout, dependență, necunoscut.
• p95/p99 mainstream latență tratament vs în redrive.
• Dimensiunea DLQ, riscul de depășire.

• Etichetele necesare sunt 'message _ id',' entity _ id', 'tenant _ id',' tentative ',' reason ',' redrive _ batch _ id'.
• Urmărirea „ramurii DLQ”: de la sursă la succesul repetat.

• Procentul de mesaje procesate cu succes ≥ X% în minutele T.
• Timp de investigare și corecție pentru cazul DLQ ≤ orele Y.
• Vârsta maximă a mesajului în orele DLQ ≤ Z (cu alertă).

11) Siguranță și conformitate

Acces cu cel mai mic privilegiu: Redrive - numai operatori/playbook-uri.
Audit: cine și când a declanșat metadatele redrive/delete/edit.
Salubritate: Atunci când transferați la DLQ central, eliminați PII/secrete inutile.
Retenție: politici separate de păstrare și ștergere pentru DLQ.

12) Multi-chirie

Etichete „chiriaș _ id/plan”: distinge limitele, redrave priorități, rapoarte.
Per-chiriaș DLQ sau părți: astfel încât clientul „zgomotos” să nu blocheze DLQ-ul general.
Facturare/cote: luați în considerare volumul DLQ și costul de redrive în utilizare.

13) Șabloane de configurare (exemplu)

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) Playbook-uri operaționale (runbooks)

1. Creștere DLQ anormală: activați accelerarea consumatorului de producție, analizați motive de top, verificați eliberările/schemele.
2. Schema de neconcordanță: schema rollback/comite, migrarea adaptorului, redrive după validare.
3. Dependență externă indisponibilă: întrerupeți reconstrucțiile, activați coada de întârziere, redistribuiți după recuperare.
4. DLQ-uri repetate după redrive: activați manipulatorul/simulatorul „shadow”, verificați idempotența, lotul îngust.
5. DLQ overflow: evacuarea la arhiva-stocare, permite redrave selectiv pentru chei/motive.

15) Testarea și haosul

Eroare la injectare: schema-break, validare, timeout-uri 1-on-N erori lipicioase.

Revizuirea în masă: verificarea dozării și a impactului asupra producției

Secvență în afara ordinii: asigurați manipularea corectă a cheii.
Corupția sarcinii utile: validare și eșec sigur.
Recuperarea după căderea lucrătorului redrive: idempotența operațiunilor lotului.

16) Erori tipice

Lipsa metadatelor în DLQ → este imposibil să se grupeze cauzele și să se modifice în siguranță.
Masa redesenează fără limite → re-degradarea producției.
Fără idempotență/duplicare → duplicate și efecte secundare.
PII amestecare în DLQ central fără salubritate.
Lipsa schemelor/contractelor → „surprize” în evoluția mesajelor.
Singurul DLQ comun fără partiționare chiriaș/cheie.
Retractări infinite în loc de DLQ timpuriu pentru erori neretrizabile.

17) Rețete rapide

Flux normal de afaceri: 3-4 încercări, backoff exponențial cu jitter, clasificarea timpurie a erorilor, DLQ cu metadate complete.
Evenimente critice (plată): idempotență strictă, termene scurte, încercări minime, DLQ rapid și parsare manuală.
Masa redesenează după fixare: loturi mici (100-500), limită de rată, grup separat de lucrători, succes de monitorizare> 95% înainte de creșterea vitezei.
Multi-chiriaș: pe chiriaș redrive limite, DLQ top client generator de raport.

Concluzie

DLQ nu este un „coș de gunoi”, ci o buclă de fiabilitate controlată. Reguli clare de succes, metadate bogate, idempotență și eliminare a duplicatelor, redrive securizate, disciplina schemei și observabilitatea transformă mesajele toxice dintr-o amenințare la adresa SLO într-un proces ingineresc ușor de gestionat - cu cărți de redare ușor de înțeles, costuri previzibile și impact minim asupra utilizatorilor.