DLQ жана уулуу билдирүүлөрдү иштетүү

Dead Letter Queue (DLQ) - бул белгиленген сандагы аракеттен кийин же так техникалык/бизнес себептерден улам (нөлдүк схема, таймаут, версиялардын чыр-чатагы ж.б.) штаттык консультант тарабынан иштетилбеген билдирүүлөр үчүн обочолонгон кезек/топик. Уулуу билдирүү (poison message) - кайра иштетүү дайыма ката менен аяктап, пайплайндын туруктуулугуна коркунуч туудурган жазуу.

DLQ максаты: SLO сактоо, ийгиликсиз локализациялоо, негизги агымдын бөгөттөлүшүнө жол бербөө жана талдоо жана коопсуз кайталоо (редрайв) мүмкүнчүлүгүн кепилдөө.

1) Уулуу билдирүүлөр кайдан алынат

Схемалар/контракттар: шайкеш келбеген өзгөрүүлөр, жок милдеттүү талаалар, туура эмес түрлөрү.
Бизнес-валидациялар: дубликаттар, бузулган инварианттар, мөөнөтү өтүп кеткен окуялар.
Тартиби жана себептери: келди "Update" чейин "Create", пропущенные корреляции, out-of-order.
Демпотенттик: кайра иштетүү терс таасирлерин пайда кылат.
Тышкы көз карандылык: чектелген чеги/убакыт, API жеткиликсиздиги.
Маалыматтар: жемкорлук, туура эмес коддоо, ашыкча өлчөмдөрү.

2) DLQ жиберүү критерийлери

• Consumer/Worker менен maxAttempts иштетүү ашып кетти.
• Ката туура эмес (non-retryable) катары классификацияланган: нөлдүк схема, критикалык ресурстун жоктугу, бизнеске тыюу салуу.
• Deadline билдирүү мөөнөтү (TTL/expiration).
• Бул ачкыч/тенант үчүн circuit breaker же admission control саясаты иштеди.
• Оператордун так чечими (негизги агымынан кол менен "eject").

3) Топологиялар жана DLQ үлгүлөрү

Per-queue DLQ: ар бир кезек/топик өз DLQ бар. Жөнөкөй жана ачык.
Central DLQ (паркинг лот): татаал учурларда жалпы "паркинг", бирдиктүү талдоо инструменттери үчүн ыңгайлуу.
DLT (Dead Letter Topic): лог-багытталган шиналар үчүн (event log) - метадеректер менен өзүнчө топик ийгиликсиз себептери.
Quarantine: кол менен талдоо үчүн катуу жетүү жана PII-санитария менен карантиндик буфер.
Shadow-stream: fix менен коопсуз эксперименттер үчүн "көлөкө" көйгөйлүү билдирүүлөрдү кайталоо.

4) DLQ менен коштолушу керек болгон метадеректер

• Баш тартуу себеби: код/ката классы, stack/trace id.
• Ретрациялардын контекст: 'attempt', 'maxAttempts', 'first _ seen _ ts', 'last _ attempt _ ts'.
• Корреляция: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', партиялаштыруу ачкычы.
• Original offset/partition/sequence (үймө шиналар үчүн) же message-id.
• Келишим/схема/пайдалуу жүктүн версиясы.
• Idempotency-key/Request-id (бар болсо).
• Багыттоо булагы: кезек аты/топика, консюмер тобу.

5) DLQ үчүн Retrains саясаты

• Кыска Retrains concumer: 'maxAttempts' 2-5, exponential backoff + життер, concurrency боюнча caps.
• Кооперативдик backpressure: каталар көбөйгөндө атаандаштыкты азайтуу.
• Каталардын классификациясы: retryable ('5xx', таймаут) vs non-retryable (валидация, схема mismatch).
• Кийинкиге калтырылган кезектер (delay queue): 5s → 30s → 2m убактылуу мүчүлүштүктөр үчүн.
• Per-key обочолонуу: "ызы-чуу" белгилүү бир ачкыч болсо, бүт партия бөгөттөп жок.

6) Коопсуз redrave (DLQ кайра жеткирүү)

Redrave - бул DLQдан кайра иштетүүгө көзөмөлгө алынган билдирүүлөр.

1. Фиксти текшерүү: кодду/конфигурацияны/схеманы оңдогондон кийин же тышкы көз карандылыктарды калыбына келтиргенден кийин гана редраив.

2. Idempotentity: кайра иштетүү үчүн туруктуу болушу керек (upsert, таасир-толуранттык иш).

3. Deduplication: 'idempotency _ key '/' message _ id '/' business _ key'.

4. Дозалоо жана терезелер: N билдирүүлөр боюнча batches, redrave боюнча rate-limit, убакыт/партиялар боюнча "терезелер".

5. Жергиликтүү валидация: редрайвге чейин схеманы тез текшерүү (алгачкы нөлдүк учурларды оңдоо).

6. Артыкчылык: Редрайв азык-түлүк трафигин алмаштырбашы керек (төмөнкү воркер артыкчылыгы/өзүнчө пул).

7. Байкоо: redrayva үчүн өзүнчө метрика жана соода; натыйжалары жөнүндө отчет (ийгилик/кайталап DLQ/жоготуу).

7) Жеткирүү семантикасы жана тартиби

At-least-once - эң кеңири таралган режим: демпотенттүүлүк жана дедупликация керек.
At-most-once - DLQ өчүрүү мүмкүн; жоготуу коркунучу. Жол берилген жоготуулар болгондо гана колдонуңуз.
Exactly-once (натыйжалуу): бизнес-сактоо менен бүтүм жана дедуп жетишилет; кымбат жана өзгөчө.
Тартиби: DLQ, адатта, белгилүү бир ачкыч/партия үчүн тартипти бузат. Эгерде тартип оор болсо, ачкыч жана ырааттуу редрайвит.

8) Схемалар, контракттар жана валидация

Schema registry/келишимдер: так чыгаруу, backward/forward-шайкештик менен эволюция.
Кириштеги валидация: оор кадамдарга чейин JSON Schema/Protobuf/Euro аркылуу арзан текшерүү.
Шайкеш келбөө саясаты: "сындыруучу" талаада - дароо DLQ 'SCHEMA _ INCOMPATIBLE' коду менен.
Redaction PII: DLQ гана зарыл сактоо; сезгич талааларды жаап.

9) Демпотенттүүлүк жана дедупликация

Idempotency-key: өндүрүүчүдө "бизнес маанисинен" (tenant + entity + operation + ts-bucket) пайда болот.
Дедуп журналдар: TTL менен акыркы 'N' ачкычтарын сактоо; операциянын "эффектин" жаттап алыңыз.
Upsert/merge: чектөөсүз "insert-only" алыс.
Side Effects: тышкы чалуулар үчүн - чалуу алдында "кайталоо" журналына жана текшерүү.

10) Байкоо жана SLO

• DLQ rate (msg/s), билдирүүлөрдүн үлүшү, DLQ орточо/орточо "жашы".
• redrave ийгилиги (%), экинчи DLQ үлүшү.
• Себептердин классификациясы: schema, validation, timeout, dependency, unknown.
• p95/p99 негизги агымын кайра иштетүү жашыруун vs.
• DLQ көлөмү, толуп кетүү коркунучу.

• Милдеттүү теги: 'message _ id', 'entity _ id', 'tenant _ id', 'attempt', 'reason', 'redrive _ batch _ id'.
• "DLQ бутактарын" издөө: булактан ийгиликке чейин.

• Ийгиликтүү иштетилген билдирүүлөрдүн үлүшү T мүнөттө X% ≥.
• DLQ иши үчүн иликтөө жана оңдоо убактысы ≤ Y саат.
• Билдирүүнүн максималдуу "жашы" DLQ ≤ Z саат (алерт менен).

11) Коопсуздук жана шайкештик

Эң аз артыкчылыктар принциби боюнча кирүү: редрайв - операторлорго/плейбуктарга гана.
Аудит: ким жана качан триггер redrave/алып салуу/мета-маалыматтарды өзгөртүү.
Санитария: central DLQ которууда кошумча PII/сырларды алып салыңыз.
Retention: DLQ үчүн өзүнчө сактоо мөөнөтү жана алып салуу саясаты.

12) Көп тенанттуулук

Tags 'tenant _ id/plan': чектерди, редрайвдын артыкчылыктарын, отчетторду айырмалаңыз.
Per-tenant DLQ же партия: "ызы-чуу" кардар жалпы DLQ балл эмес.
Биллинг/квота: DLQ көлөмүн жана редрайвдын баасын эске алуу usage.

13) Конфигурациялык үлгүлөр (мисал)

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) иштетүү Playbooks (runbooks)

1. DLQ Анормалдуу өсүшү: throttling прод-менеджер, жогорку себептерин талдоо, релиздерди/схемаларды текшерүү кирет.
2. Shema mismatch: артка/бекитүү схемасы, адаптер көчүрүү, текшерүү кийин redrive.
3. Тышкы көз карандылык жеткиликтүү эмес: тыныгуу retrains, delay-кезек күйгүзүү, калыбына кийин redrive.
4. кайталап DLQ кийин Редрайв: "көмүскө" иштеп чыгуучу/симулятор күйгүзүү, Идемпотенттикти текшерүү, майдалоо.
5. DLQ толуп: архивге көчүрүү, ачкычтар/себептер боюнча тандалма редрайвды киргизүү.

15) сыноо жана башаламандык

Каталарды киргизүү: schema-break, валидация, таймауттар, 1-на-N "жабышчаак" каталар.
Массалык Редрайв: дозалоону жана прод.
Out-of-order ырааттуулугу: ensure ачкычтар боюнча туура иштетүү.
жемкорлук: валидация жана коопсуз баш тартуу.
Redrave Worker кулагандан кийин калыбына келтирүү: Идемпотенттүүлүк batch-операциялар.

16) типтүү каталар

DLQ → метадерилери жоктугу себептерин кластердик жана коопсуз redrayvit мүмкүн эмес.
чектери жок массалык redrave → кайра өндүрүштүн деградация.
Эч кандай демпотенттик/дедупа → кош жана терс таасирлери.
PII борбордук DLQ тазалоо жок аралаштыруу.
Жок схемалар/келишимдер → "күтүлбөгөн" кабар эволюция.
Тенанттар/ачкычтар боюнча партиялашуусуз жалгыз жалпы DLQ.
Чексиз Retray ордуна эрте DLQ үчүн non-retryable каталар.

17) Тез Recipes

Кадимки бизнес-агым: 3-4 аракет, экспоненциалдуу backoff менен jitter, эрте ката классификация, DLQ толук метадеректер менен.
Критикалык окуялар (төлөм): катуу боштук, кыска убакыт, минималдуу аракет, тез DLQ жана кол талдоо.
fix кийин массалык redrave: small batches (100-500), rate-limit, өзүнчө worker бассейн, ийгиликке мониторинг> 95% ылдамдыгын жогорулатуу алдында.
Мульти-тенант: Редрайвге пер-тенанттык лимиттер, DLQ топ-кардар генераторлору боюнча отчет.

Корутунду

DLQ - бул "таштанды куржуну" эмес, башкарылуучу ишенимдүүлүк контуру. Так атуу эрежелери, бай мета-маалыматтар, демпотенттүүлүк жана дедупликация, коопсуз дозаланган редрайв, схемалардын тартиби жана байкоо жөндөмдүүлүгү SLO үчүн коркунучтан уулуу билдирүүлөрдү башкарылуучу инженердик процесске айландырат - түшүнүктүү плейбуктар, болжолдонгон чыгымдар жана колдонуучуларга минималдуу таасир.