DLQ und die Verarbeitung giftiger Nachrichten

Dead Letter Queue (DLQ) ist eine isolierte Warteschlange/Spitze für Nachrichten, die von einem Vollzeit-Consumer nach einer bestimmten Anzahl von Versuchen oder aus offensichtlichen technischen/geschäftlichen Gründen (nicht valides Schema, Timeout, Versionskonflikt usw.) nicht verarbeitet werden konnten. Poison message (giftige Nachricht) - eine Aufzeichnung, deren erneute Verarbeitung stabil fehlschlägt und die Stabilität der Pipeline gefährdet.

Das Ziel von DLQ ist es, SLO zu erhalten, den Fehler zu lokalisieren, die Blockierung des Hauptstroms zu verhindern und die Fähigkeit zur Analyse und sicheren Reproduktion (Redrive) zu gewährleisten.

1) Woher die giftigen Botschaften kommen

Schemata/Verträge: inkompatible Änderungen, fehlende Pflichtfelder, falsche Typen.
Geschäftsvalidierungen: Duplikate, gestörte Invarianten, überfällige Ereignisse.
Ordnung und Kausalität: kam „Update“ zu „Create“, fehlende Korrelationen, out-of-order.
Idempotenz: Wiederholte Behandlung erzeugt Nebenwirkungen.
Externe Abhängigkeiten: begrenzte Limits/Timeouts, API-Unzugänglichkeit.
Daten: Nutzlastkorruption, falsche Codierung, Überdimensionierung.

2) Kriterien für den Versand an DLQ

• MaxAttempts der Verarbeitung beim Consumer/Worker überschritten.
• Der Fehler wird als unverbesserlich (non-retryable) eingestuft: ein nicht valides Schema, das Fehlen einer kritischen Ressource, ein Geschäftsverbot.
• Die Nachricht deadline (TTL/expiration) ist abgelaufen.
• Die Richtlinie circuit breaker oder admission control für einen gegebenen Schlüssel/Tenant hat funktioniert.
• Explizite Bedienerentscheidung (manuelles „eject“ aus dem Hauptstrom).

3) DLQ Topologien und Muster

Per-queue DLQ: Jede Warteschlange/jeder Punkt hat seinen eigenen DLQ. Einfach und transparent.
Central DLQ (parking lot): Gemeinsames „Parken“ für komplexe Fälle, praktisch für einheitliche Analysetools.
DLT (Dead Letter Topic): Für Log-orientierte Busse (Event Log) ein separates Topic mit Metadaten der Fehlerursache.
Quarantine: Quarantänepuffer mit hartem Zugang und PII-Desinfektion für die manuelle Analyse.
Shadow-Stream: Duplizieren problematischer Nachrichten im „Schatten“ für sichere Fixierexperimente.

4) Metadaten, die DLQ begleiten müssen

• Fehlerursache: Fehlercode/Klasse, Stack/Trace ID.
• Kontext der Retrays: 'attempt', 'maxAttempts',' first _ seen _ ts', 'last _ attempt _ ts'.
• Korrelation: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', Partitionierungsschlüssel.
• Original offset/partition/sequence (für Logbusse) oder message-id.
• Vertrag/Schema/Version der Nutzlast.
• Idempotency-key/Request-id (falls vorhanden).
• Routing-Quelle: Warteschlangen-/Topic-Name, Consumer-Gruppe.

5) Retrayrichtlinien vor DLQ

• Kurze Retrays des Verbrauchers: 'maxAttempts' 2-5, exponentieller Backoff + Jitter, Caps auf Concurrency.
• Kooperative Backpress: Weniger Wettbewerb bei steigenden Fehlern.
• Fehlerklassifizierung: retryable ('5xx', timeout) vs non-retryable (Validierung, schema mismatch).
• Verzögerte Warteschlangen: 5s → 30s → 2m für temporäre Ausfälle.
• Per-Key-Isolierung: Wenn ein bestimmter Schlüssel „rauscht“, blockieren Sie nicht die gesamte Party.

6) Sicherer redrive (Neulieferung von DLQ)

Redrive ist die kontrollierte Rückgabe von Nachrichten von DLQ an die Verarbeitung.

1. Fix-Check: Redrive nur nach Korrektur des Codes/der Konfiguration/des Schemas oder nach Wiederherstellung externer Abhängigkeiten.

2. Idempotenz: Die Behandler müssen wiederholungsresistent sein (Upsert, Effekt-Toluant-Operationen).

3. Deduplizierung: durch 'idempotency _ key '/' message _ id '/' business _ key'.

4. Dosierung und Fenster: Batches durch N Nachrichten, Rate-Limit auf redrive, „Fenster“ durch Zeit/Partitionen.

5. Lokale Validierung: schnelle Überprüfung des Schemas vor dem Redrive (Reject von frühen nicht-validen Fällen).

6. Priorität: Der Redrive darf den Longitudinalverkehr nicht verdrängen (niedrige Priorität der Worker/separater Pool).

7. Beobachtbarkeit: separate Metriken und Traces für redrive; Ergebnisbericht (Erfolg/wiederholtes DLQ/Verlust).

7) Semantik der Lieferung und Ordnung

At-least-once ist der häufigste Modus: Idempotenz und Deduplizierung sind erforderlich.
At-most-once - DLQ kann deaktiviert werden; Verlustrisiko. Nur bei zulässigen Verlusten verwenden.
Exactly-once (effektiv): erreicht durch Transaktionen und Deduplizierung im Geschäftsspeicher; teuer und spezifisch.
Reihenfolge: DLQ bricht normalerweise die Reihenfolge für einen bestimmten Schlüssel/eine bestimmte Partei ab. Wenn die Reihenfolge kritisch ist, redrivite durch den Schlüssel und konsequent.

8) Schemata, Verträge und Validierung

Schema-Registry/Verträge: Klare Versionierung, Evolution mit Backward/Forward-Kompatibilität.
Validierung am Eingang: Kostengünstige Verifizierung durch JSON Schema/Protobuf/Avro vor schweren Schritten.
Inkompatibilitätsrichtlinie: Wenn das Feld „bricht“ - sofort im DLQ mit dem Code' SCHEMA _ INCOMPATIBLE'.
Redaction PII: Speichern Sie nur das, was Sie in DLQ benötigen; empfindliche Felder maskieren.

9) Idempotenz und Deduplizierung

Idempotency-key: Bilden Sie auf dem Hersteller aus dem „Business-Sinn“ (tenant + entity + operation + ts-bucket).
Dedup-Protokolle: Speichern Sie die letzten'N 'Schlüssel mit TTL; Erinnern Sie sich an den „Effekt“ der Operation.
Upsert/merge: Vermeiden Sie „insert-only“ ohne Einschränkungen.
Side-Effekte: für externe Anrufe - protokollieren und überprüfen Sie die „Wiederholung“ vor dem Anruf.

10) Beobachtbarkeit und SLO

• DLQ-Rate (msg/s), Anteil der Meldungen, mittleres/medianes „Alter“ im DLQ.
• Redrive-Erfolg (%), wiederholter DLQ-Anteil.
• Klassifizierung der Ursachen: Schema, Validierung, Timeout, Abhängigkeit, unbekannt.
• p95/p99 Hauptstrom-Verarbeitungslatenz vs in redrive.
• DLQ-Größe, Überlaufgefahr.

• Erforderliche Tags: 'message _ id', 'entity _ id', 'tenant _ id', 'attempt', 'reason', 'redrive _ batch _ id'.
• Tracing „DLQ Branch“: von der Quelle zum wiederholten Erfolg.

• Der Anteil der erfolgreich verarbeiteten Nachrichten ≥ X% pro T Minuten.
• Untersuchungszeit und Korrekturen für DLQ-Fall ≤ Y Stunden.
• Das maximale „Alter“ der Nachricht in DLQ ≤ Z Stunden (mit alert).

11) Sicherheit und Compliance

Zugriff nach dem Prinzip der geringsten Privilegien: redrive - nur für Operatoren/Playbooks.
Audit: Wer und wann hat Redrive/Löschen/Bearbeiten von Metadaten ausgelöst.
Desinfektion: Entfernen Sie überschüssige PIIs/Geheimnisse, wenn Sie in das zentrale DLQ übertragen werden.
Retention: separate Aufbewahrungsfristen und Löschrichtlinien für DLQ.

12) Multi-Tenante

Tags' tenant _ id/plan': Grenzen, redrive Prioritäten, Berichte unterscheiden.
Per-tenante DLQs oder Parties: Damit der „laute“ Kunde nicht den gesamten DLQ erzielt.
Abrechnung/Quoten: Berücksichtigen Sie das DLQ-Volumen und die Redrive-Kosten pro Nutzung.

13) Konfigurationsvorlagen (Beispiel)

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) Operative Playbooks (Runbooks)

1. Abnormales DLQ-Wachstum: Schalten Sie den Drottling des Prod-Verbrauchers ein, analysieren Sie die Top-Ursachen, überprüfen Sie die Releases/Diagramme.
2. Schema mismatch: Schema Rollback/Commit, Adaptermigration, Redrive nach Prüfung.
3. Die externe Abhängigkeit ist nicht verfügbar: Anhalten der Retrays, Aktivieren der Delay-Warteschlange, Redrive nach der Wiederherstellung.
4. Wiederholte DLQs nach dem Redrive: Aktivieren Sie den „Schatten“ -Handler/Simulator, überprüfen Sie die Idempotenz, verengen Sie die Batch.
5. DLQ-Überlauf: Evakuierung in Archiv-Speicher, aktivieren Sie selektive redrive durch Schlüssel/Ursachen.

15) Testen und Chaos

Fehlerinjektion: Schema-Break, Validierung, Timeouts, 1-on-N „klebrige“ Fehler.
Massenredrive: Überprüfung der Dosierung und des Einflusses auf prod.
Out-of-Order-Sequenz: ensure korrekte Verarbeitung durch Schlüssel.
Payload Korruption: Validierung und sichere Ablehnung.
Erholung nach dem Fall des Redrive Worker: Idempotenz von Batch-Operationen.

16) Typische Fehler

Das Fehlen von Metadaten in DLQ ist → unmöglich, Ursachen zu clustern und sicher zu redividieren.
Massenredrive ohne Grenzen → Re-Degradation der Produktion.
Keine idempotency/deduplex → takes und Nebenwirkungen.
Mischen von PII im zentralen DLQ ohne Desinfektion.
Das Fehlen von Schemata/Verträgen → „Überraschungen“ bei der Entwicklung von Nachrichten.
Der einzige gemeinsame DLQ ohne Tenant/Key-Partitionierung.
Endlose Retrays statt früher DLQ für nicht-retryable Fehler.

17) Schnelle Rezepte

Normaler Geschäftsfluss: 3-4 Versuche, exponentieller Backoff mit Jitter, frühe Fehlerklassifizierung, DLQ mit vollständigen Metadaten.
Kritische Ereignisse (Zahlung): strenge Idempotenz, kurze Timeouts, minimale Versuche, schnelle DLQ und manuelle Analyse.
Massen-Redrive nach Fix: kleine Batches (100-500), Rate-Limit, separater Worker-Pool, Erfolgskontrolle> 95% vor Geschwindigkeitserhöhung.
Multi-Tenant: Per-Tenant-Grenzen für Redrive, Bericht über Top-DLQ-Generator-Kunden.

Schlussfolgerung

DLQ ist kein „Mülleimer“, sondern ein kontrollierter Zuverlässigkeitskreislauf. Klare Trefferregeln, reichhaltige Metadaten, Idempotenz und Deduplizierung, sicheres dosiertes Redrive, Disziplin der Schemata und Beobachtbarkeit verwandeln giftige Botschaften von einer Bedrohung für SLOs in einen überschaubaren Engineering-Prozess - mit verständlichen Playbooks, vorhersehbaren Kosten und minimalen Auswirkungen auf die Nutzer.