Obsługa wiadomości DLQ i trucizny

Queue Dead Letter (DLQ) to odosobniona kolejka/temat wiadomości, które nie mogły być przetwarzane przez zwykłego konsumenta po określonej liczbie prób lub z oczywistych powodów technicznych/biznesowych (nieprawidłowy schemat, timeout, konflikt wersji itp.). Komunikat trucizny - zapis, którego regeneracja konsekwentnie zawodzi i zagraża stabilności rurociągu.

Celem DLQ jest zachowanie SLO, zlokalizowanie awarii, zapobieganie blokowaniu głównego strumienia i zagwarantowanie możliwości analizy i bezpiecznego powtórzenia (redrave).

1) Skąd pochodzą jadowite wiadomości

Schematy/umowy: niezgodne ze wspólnym rynkiem zmiany, brakujące wymagane pola, nieprawidłowe typy.
Walidacje biznesowe: duplikaty, nieustanne naruszenia, wygasłe zdarzenia.
Porządek i przyczynowość: przyszedł „Update” do „Create”, brakujące korelacje, out-of-order.
Idempotencja: ponowne przetwarzanie generuje skutki uboczne.
Zależność zewnętrzna: ograniczone limity czasowe, niedostępność API.
Dane: uszkodzenie ładunku, nieprawidłowe kodowanie, nadmierne rozmiary.

2) Kryteria składania DLQ

• Przekroczył maxPróby przetwarzania u konsumenta/pracownika.
• Błąd jest klasyfikowany jako niepowtarzalny: nieprawidłowy system, brak krytycznego zasobu, zakaz prowadzenia działalności.
• Wiadomość o terminie (TTL/wygaśnięcie) wygasła.
• Dla tego klucza/najemcy uruchomiono zasadę wyłącznika lub kontroli wjazdu.
• Rozwiązanie operatora (ręczne „wyrzucić” z głównego wątku).

3) topologie i wzory DLQ

DLQ na kolejkę: każda kolejka/temat ma swój własny DLQ. Proste i przejrzyste.
Centralny DLQ (parking): ogólne „parking” dla złożonych przypadków, wygodne dla ujednoliconych narzędzi analizy.
DLT (Dead Letter Topic): dla autobusów zorientowanych na dziennik (log zdarzeń) - osobny temat z metadanymi przyczyny awarii.
Kwarantanna: bufor kwarantanny z łatwym dostępem i urządzeniem sanitarnym PII do ręcznej analizy.
Cień-strumień: Powielanie problematycznych wiadomości w „cień” dla bezpiecznych eksperymentów utrwalania.

4) Metadane wymagane do towarzyszenia DLQ

• Powód awarii: kod błędu/klasa, stos/identyfikator śledzenia.
• Kontekst retrasy: 'próba', 'maxAttempts', 'first _ seen _ ts',' last _ attempt _ ts'.
• Korelacja: 'trace _ id',' span _ id', 'lokator _ id',' entity _ id', klucz partycji.
• Oryginalny przesunięcie/partycja/sekwencja (dla autobusów dziennika) lub wiadomość-id.
• Wersja kontraktowa/schemat/ładunek użytkowy.
• Idempotence-key/Request-id (jeśli istnieje).
• Źródło routingu: nazwa/temat kolejki, grupa konsumentów.

5) Polityka retray przed DLQ

• Krótkie przekaźniki konsumenckie: 'maxAttempts' 2-5, wykładnicze backoff + jitter, czapki na jednoczesność.
• Kooperacyjne obciążenie zwrotne: Zmniejszenie konkurencji w miarę wzrostu błędów.
• Klasyfikacja błędów: możliwe do odzyskania ('5xx', timeout) vs non-retryyyable (walidacja, niedopasowanie schematu).
• Kolejki opóźnień: 5s → 30s → 2m dla awarii tymczasowych.
• Izolacja per-key: jeśli konkretny klucz jest „hałaśliwy”, nie blokuj całej partii.

6) Bezpieczne Redrive (Redelivery z DLQ)

Redrive jest kontrolowanym zwrotem wiadomości z DLQ do przetwarzania.

1. Sprawdź poprawkę: przerobić tylko po ustaleniu kodu/konfiguracji/schematu lub po przywróceniu zewnętrznych zależności.

2. Idempotencja: obsługujący muszą być odporni na powtarzanie (upsert, operacje efektowo-tolucyjne).

3. Deduplikowanie przez 'idempotence _ key '/' message _ id'/' business _ key'.

4. Pakowanie i okna: partie według wiadomości N, limit szybkości przez przekierowanie, „okna” przez czas/strony.

5. Walidacja lokalna: szybka weryfikacja systemu przed przeredagowaniem (odrzucenie wczesnych nieprawidłowych przypadków).

6. Priorytet: Przekierowanie nie powinno przesunąć ruchu sprzedaży (niski priorytet pracowników/indywidualnej puli).

7. Obserwowalność: poszczególne mierniki i szlaki do przekroju; raport wyników (sukces/powtórzenie DLQ/strata).

7) Semantyka dostawy i zamówienie

Co najmniej raz jest najczęstszym trybem: wymagana jest idempotencja i deduplikacja.
Co najwyżej - DLQ może być wyłączony; ryzyko strat. Stosować tylko wtedy, gdy straty są dopuszczalne.
Dokładnie raz (efektywnie): osiągnięte poprzez transakcje i deduplikacje w magazynach; drogie i specyficzne.
Zamówienie: DLQ zwykle łamie zamówienie dla konkretnego klucza/strony. Jeśli zamówienie jest krytyczne, redraw przez klucz i kolejno.

8) Systemy, umowy i walidacja

Schemat rejestru/kontraktów: jasne wersioning, ewolucja z kompatybilności wstecznej/forward.
Walidacja przy wejściu: tanie sprawdzenie przez JSON Schema/Protobuf/Avro przed ciężkimi krokami.
Polityka niezgodności: z „łamaniem” pola - natychmiast w DLQ z kodem 'SCHEMA _ INCOMPATIBLE'.
Redaction PII: Przechowywać tylko to, czego potrzebujesz w DLQ; pola wrażliwe na maski.

9) Idempotencja i deduplikacja

Idempotency-key: formularz na temat producenta z „business sense” (najemca + podmiot + operacja + ts-wiadro).
Dzienniki Deadup: przechowywać ostatnie klucze 'N' z TTL; zapamiętaj „efekt” operacji.
Upsert/merge: Unikaj „insert-only” bez ograniczeń.
Skutki uboczne: dla połączeń zewnętrznych - zaloguj i sprawdź „powtórzyć” przed wywołaniem.

10) Obserwowalność i SLO

• Wskaźnik DLQ (msg/s), odsetek wiadomości, średnia/mediana „wieku” w DLQ.
• Sukces redrave (%), powtarzający się udział DLQ.
• Klasyfikacja przyczyn: schemat, walidacja, czas, zależność, nieznana.
• p95/p99 leczenie głównego nurtu latency vs redrive.
• Rozmiar DLQ, ryzyko przepełnienia.

• Wymagane znaczniki to 'message _ id',' entity _ id', 'tenant _ id',' try ',' reason ',' redrive _ batch _ id'.
• Śledzenie „gałęzi DLQ”: od źródła do wielokrotnego sukcesu.

• Odsetek wiadomości pomyślnie przetworzonych ≥ X% w minutach T.
• Czas badania i korekty w przypadku DLQ ≤ godz.
• Maksymalny „wiek” wiadomości w DLQ ≤ Z godzin (z wpisem).

11) Bezpieczeństwo i zgodność

Najmniejszy dostęp: Redrive - tylko operatorzy/playbooks.
Audyt: kto i kiedy uruchomił redrive/delete/edit metadane.
Sanitation: Podczas przenoszenia do centralnego DLQ, usunąć zbędne PII/tajemnice.
Zatrzymanie: oddzielne zasady przechowywania i usuwania DLQ.

12) Wielozatrudnienie

Tagi „najemca _ id/plan”: odróżnić limity, przeredagować priorytety, raporty.
Per-najemca DLQ lub strony: tak, że „hałaśliwy” klient nie zatyka ogólnego DLQ.
Rozliczenie/kwoty: należy wziąć pod uwagę wielkość DLQ i koszt ponownego wykorzystania.

13) Szablony konfiguracji (przykład)

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) Operacyjne playbooks (książki startowe)

1. Nieprawidłowy wzrost DLQ: włączyć przepuszczanie konsumenta produkcyjnego, przeanalizować najważniejsze powody, sprawdzić wersje/programy.
2. Niedopasowanie schematu: schemat rollback/commit, migracja adaptera, przekierowanie po walidacji.
3. Zewnętrzna zależność niedostępna: przerwać przekładnie, włączyć kolejkę opóźnień, przekierować po odzyskaniu.
4. Powtarzające się DLQ po przekierowaniu: włącz obsługę/symulator „shadow”, sprawdź iempotencję, wąską partię.
5. Przepełnienie DLQ: ewakuacja do archiwum-pamięci masowej, umożliwienie selektywnego przeredagowania z kluczy/powodów.

15) Testowanie i chaos

Wtrysk błędu: schemat-break, walidacja, timeouts, 1-on-N lepkie błędy.

Masowa rewizja: kontrola dawkowania i wpływu na produkcję

Sekwencja poza zamówieniem: zapewnić prawidłową obsługę klucza.
Uszkodzenie ładunku: walidacja i bezpieczna awaria.
Odzyskiwanie po upadku redrive pracownika: idempotencja operacji serii.

16) Typowe błędy

Brak metadanych w DLQ → jest niemożliwe do klastrowania przyczyn i bezpiecznej modyfikacji.
Masowe przeróbki bez ograniczeń → ponowna degradacja produkcji.
Brak idempotencji/deduplikacji → duplikaty i skutki uboczne.
Mieszanie PII w centralnym DLQ bez urządzeń sanitarnych.
Brak systemów/umów → „niespodzianki” w ewolucji wiadomości.
Jedyny wspólny DLQ bez podziału lokatora/klucza.
Nieskończone przekładki zamiast wczesnego DLQ dla błędów niepowtarzalnych.

17) Szybkie przepisy kulinarne

Normalny przepływ biznesowy: 3-4 próby, wykładnicze backoff z jitter, wczesna klasyfikacja błędów, DLQ z pełnymi metadanymi.
Zdarzenia krytyczne (płatność): ścisła idempotencja, krótkie czasy, minimalne próby, szybki DLQ i ręczne parsowanie.
Masa przerobiona po ustaleniu: małe partie (100-500), limit szybkości, oddzielna pula pracowników, sukces monitoringu> 95% przed zwiększeniem prędkości.
Multi-najemca: limit redrive na najemcę, raport generatora klienta DLQ.

Wnioski

DLQ nie jest „śmieciarką”, ale kontrolowaną pętlą niezawodności. Jasne zasady hitu, bogate metadane, idempotencja i deduplikacja, bezpieczne pomiarowe redrive, schemat dyscypliny i obserwowalność przekształcić toksyczne wiadomości z zagrożenia SLO w zarządzany proces inżynieryjny - z zrozumiałymi playbooks, przewidywalne koszty i minimalny wpływ na użytkowników.