DLQ و دست زدن به پیام سمی

صف نامه مرده (DLQ) یک صف/موضوع جداگانه برای پیام هایی است که نمی تواند توسط یک مصرف کننده معمولی پس از تعداد معینی از تلاش ها یا به دلایل فنی/تجاری آشکار (طرح نامعتبر، وقفه، درگیری نسخه و غیره) پردازش شود. پیام سمی - رکوردی که پردازش مجدد آن به طور مداوم شکست می خورد و ثبات خط لوله را تهدید می کند.

هدف DLQ حفظ SLO، محلی سازی شکست، جلوگیری از مسدود کردن جریان اصلی و تضمین امکان تجزیه و تحلیل و پخش ایمن (redrave) است.

1- پیام های سمی از کجا می آیند

طرحواره ها/قراردادها: تغییرات ناسازگار، فیلدهای مورد نیاز، انواع نادرست.
اعتبار کسب و کار: تکراری، نقض ناوردا، رویدادهای منقضی شده.
نظم و علیت: آمد «به روز رسانی» به «ایجاد»، همبستگی از دست رفته، خارج از ترتیب.
Idempotency: پردازش مجدد عوارض جانبی ایجاد می کند.
وابستگی های خارجی: محدودیت های محدود/زمان بندی، عدم دسترسی API.
داده ها: فساد payload، رمزگذاری نادرست، بیش از حد.

2) معیارهای ارسال DLQ

• بیش از حد maxAttempts پردازش در مصرف کننده/کارگر.
• این خطا به عنوان غیر قابل برگشت طبقه بندی شده است: طرح نامعتبر، عدم وجود یک منبع حیاتی، ممنوعیت کسب و کار.
• پیام مهلت (TTL/انقضا) به پایان رسیده است.
• قطع کننده مدار یا سیاست کنترل پذیرش برای این کلید/مستاجر ایجاد شد.
• راه حل اپراتور صریح (دستی «خروج» از موضوع اصلی).

3) توپولوژی و الگوهای DLQ

هر صف DLQ: هر صف/موضوع DLQ خود را دارد. ساده و شفاف

DLQ مرکزی (پارکینگ): «پارکینگ» عمومی برای موارد پیچیده، مناسب برای ابزارهای تجزیه و تحلیل یکپارچه.
DLT (Dead Letter Topic): برای اتوبوسهای log-oriented (event log) - یک موضوع جداگانه با ابرداده دلیل شکست.
قرنطینه: بافر قرنطینه با دسترسی سخت و بهداشت PII برای تجزیه و تحلیل دستی.
Shadow-stream: تکثیر پیام های مشکل ساز در یک «سایه» برای آزمایش های تثبیت امن.

4) ابرداده مورد نیاز برای همراه DLQ

• دلیل شکست: کد خطا/کلاس، شناسه پشته/ردیابی.
• زمینه بازخوانی: 'تلاش'، 'maxAttempts'، 'first _ seen _ ts'، 'last _ attempt _ ts'.
• همبستگی: 'trace _ id'، 'span _ id'، 'tenant _ id'، 'entity _ id'، کلید پارتیشن.
• افست اصلی/پارتیشن/دنباله (برای اتوبوس ورود به سیستم) و یا پیام ID.
• نسخه قرارداد/طرح/بارگیری.
• Idempotency-key/Request-id (در صورت وجود).
• منبع مسیریابی: نام/موضوع صف، گروه مصرف کننده.

5) سیاست های بازپرداخت قبل از DLQ

• retrays مصرف کننده کوتاه: 'maxAttempts' 2-5، عقب نشینی نمایی + لرزش، کلاه در همزمانی.
• کوله پشتی تعاونی: کاهش رقابت به عنوان اشتباهات رشد می کند.
• طبقه بندی خطا: قابل برگشت ('5xx'، timeout) در مقابل غیر قابل برگشت (اعتبار سنجی، عدم تطابق طرح).
• صف های تاخیر: 5s → 30s → 2m برای خرابی های موقت.
• جداسازی کلید: اگر یک کلید خاص «پر سر و صدا» باشد، کل حزب را مسدود نکنید.

6) Redrive امن (Redelivery از DLQ)

Redrive بازگشت کنترل شده پیام ها از DLQ به پردازش است.

1. بررسی ثابت: فقط پس از اصلاح کد/پیکربندی/طرح یا پس از بازگرداندن وابستگی های خارجی، دوباره ترسیم کنید.

2. Idempotency: گردانندگان باید در برابر تکرار (عملیات uppert، effect-toluant) مقاوم باشند.

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

4. دسته بندی و پنجره ها: دسته های N پیام، محدودیت نرخ توسط redrive، «پنجره ها» توسط زمان/احزاب.

5. اعتبارسنجی محلی: تأیید سریع طرح قبل از ترسیم مجدد (رد موارد نامعتبر اولیه).

6. اولویت: دنده قرمز نباید جایگزین ترافیک فروش شود (اولویت پایین کارگران/استخر فردی).

7. قابلیت مشاهده: معیارهای فردی و مسیرهای پیاده روی برای redrive ؛ گزارش نتیجه (موفقیت/تکرار DLQ/از دست دادن).

7) معانی تحویل و سفارش

حداقل یک بار رایج ترین حالت است: idempotence و deduplication مورد نیاز است.
در بیشتر مواقع - DLQ را می توان غیرفعال کرد. خطر از دست دادن فقط زمانی استفاده کنید که زیانها قابل قبول باشند.

دقیقا یک بار (کارآمد): به دست آمده توسط معاملات و deduplication در ذخیره سازی کسب و کار ؛ گران و خاص

سفارش: DLQ معمولا سفارش یک کلید/حزب خاص را می شکند. اگر سفارش مهم است، با کلید و به ترتیب دوباره ترسیم کنید.

8) طرح ها، قراردادها و اعتبار سنجی

رجیستری طرح/قرارداد: نسخه روشن، تکامل با سازگاری عقب/جلو.
اعتبار سنجی در ورودی: بررسی ارزان از طریق JSON Schema/Protobuf/Avro قبل از مراحل سنگین.
سیاست ناسازگاری: با یک فیلد «شکستن» - بلافاصله در DLQ با کد «SCHEMA _ INCOMPATENT».

Redaction PII: فقط آنچه را که در DLQ نیاز دارید ذخیره کنید. فیلدهای حساس به ماسک

9) Idempotency و deduplication

Idempotency-key: فرم در تولید کننده از «حس کسب و کار» (مستاجر + نهاد + عملیات + T-سطل).
سیاهههای مربوط به Deadup: آخرین کلیدهای N را با TTL نگه دارید. «اثر» عملیات را به یاد داشته باشید.
Upsert/merge: بدون محدودیت از «insert-only» اجتناب کنید.
عوارض جانبی: برای تماس های خارجی - ورود و بررسی «تکرار» قبل از تماس.

10) قابلیت مشاهده و SLO

• نرخ DLQ (msg/s)، نسبت پیام ها، میانگین/میانه «سن» در DLQ.
• موفقیت redrave (٪)، سهم DLQ تکرار شده است.
• طبقه بندی علل: طرح، اعتبار سنجی، timeout، وابستگی، ناشناخته است.
• p95/p99 تاخیر درمان اصلی در مقابل در redrive.
• اندازه DLQ، خطر سرریز.

• برچسب های مورد نیاز 'message _ id', 'entity _ id', 'tenant _ id', 'تلاش', 'reason', 'redrive _ batch _ id'.
• ردیابی «شاخه DLQ»: از منبع تا موفقیت مکرر.

• درصد پیام های پردازش شده با موفقیت X٪ در T دقیقه ≥.
• زمان بررسی و اصلاح مورد DLQ ≤ Y ساعت.
• حداکثر «سن» پیام در ساعت DLQ ≤ Z (با هشدار).

11) ایمنی و انطباق

دسترسی حداقل امتیاز: Redrive - اپراتورها/playbooks تنها.
ممیزی: چه کسی و چه زمانی باعث ایجاد ابرداده redrive/delete/edit شد.
بهداشت: هنگام انتقال به DLQ مرکزی، PII/اسرار غیر ضروری را حذف کنید.
نگهداری: سیاست های نگهداری و حذف جداگانه برای DLQ.

12) چند اجاره ای

برچسب ها 'tenant _ id/plan': محدودیت ها را تشخیص دهید، اولویت ها را بازنویسی کنید، گزارش ها.
DLQ یا احزاب: به طوری که مشتری «پر سر و صدا» DLQ کلی را مسدود نمی کند.
صورتحساب/سهمیه: در نظر گرفتن حجم DLQ و هزینه redrive در استفاده.

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 غیر طبیعی: روشن کردن مصرف کننده تولید، تجزیه و تحلیل دلایل بالا، بررسی انتشار/طرح.
2. عدم تطابق طرح: rollback/commit طرح، مهاجرت آداپتور، redrive پس از اعتبار سنجی.
3. وابستگی خارجی در دسترس نیست: مکث مجدد، فعال کردن صف تاخیر، redrive پس از بازیابی.
4. DLQs تکرار پس از redrive: فعال کردن «سایه» گرداننده/شبیه ساز، بررسی idempotency، دسته ای باریک.
5. سرریز DLQ: تخلیه به بایگانی ذخیره سازی، فعال کردن مجدد انتخابی برای کلید/دلایل.

15) آزمایش و هرج و مرج

تزریق خطا: schema-break، validation، timeouts 1-on-N خطاهای چسبنده.

تجدید نظر توده: بررسی دوز و تاثیر بر تولید

دنباله خارج از ترتیب: اطمینان از دست زدن به کلید صحیح.

فساد payload: اعتبار سنجی و شکست امن

بازیابی پس از سقوط کارگر redrive: توانایی عملیات دسته ای.

16) خطاهای معمول

عدم وجود ابرداده در DLQ → غیر ممکن است به خوشه علل و با خیال راحت تغییر دهید.
بازآفرینی انبوه بدون محدودیت → تخریب مجدد تولید.
بدون idemotency/deduplication → تکراری و عوارض جانبی.
PII مخلوط در DLQ مرکزی بدون بهداشت.
فقدان طرح ها/قراردادها → «شگفتی» در تکامل پیام ها.
تنها DLQ رایج بدون پارتیشن بندی مستاجر/کلید.
Retrays بی نهایت به جای DLQ اولیه برای خطاهای غیر قابل برگشت.

17) دستور العمل های سریع

جریان عادی کسب و کار: 3-4 تلاش، عقب نشینی نمایشی با لرزش، طبقه بندی اولیه خطاها، DLQ با ابرداده کامل.
رویدادهای بحرانی (پرداخت): idempotence دقیق، زمان کوتاه، حداقل تلاش، DLQ سریع و تجزیه دستی.
دسته های کوچک (100-500)، نرخ محدود، استخر جداگانه کارگران، نظارت بر موفقیت> 95٪ قبل از افزایش سرعت.
چند مستاجر: هر مستاجر redrive محدودیت، DLQ گزارش ژنراتور مشتری بالا.

نتیجه گیری

DLQ یک «سطل زباله» نیست، بلکه یک حلقه قابلیت اطمینان کنترل شده است. قوانین ضربه روشن، ابرداده غنی، idempotency و deduplication، redrive اندازه گیری امن، نظم و انضباط طرح و مشاهده به نوبه خود پیام های سمی از یک تهدید به SLO به یک فرایند مهندسی قابل کنترل - با playbooks قابل درک، هزینه های قابل پیش بینی و حداقل تاثیر بر کاربران.