DLQ ومعالجة الرسائل السامة

قائمة انتظار الحروف الميتة (DLQ) هي قائمة انتظار/موضوع معزول للرسائل التي لا يمكن معالجتها من قبل المستهلك العادي بعد عدد معين من المحاولات أو لأسباب فنية/تجارية واضحة (مخطط غير صالح، مهلة، تعارض النسخة، إلخ). رسالة سامة - سجل تفشل إعادة معالجته باستمرار وتهدد استقرار خط الأنابيب.

الغرض من DLQ هو الحفاظ على SLO، وتوطين الفشل، ومنع حجب التيار الرئيسي وضمان إمكانية التحليل وإعادة التشغيل الآمن (إعادة الصياغة).

1) من أين تأتي الرسائل السامة

المخططات/العقود: تغييرات غير متوافقة، فقدان المجالات المطلوبة، أنواع غير صحيحة.
التحقق من صحة الأعمال: تكرارات، ثوابت منتهكة، أحداث منتهية الصلاحية.
النظام والسببية: جاء «تحديث» لـ «إنشاء»، ارتباطات مفقودة، خارج النظام.
الخصوصية: تؤدي إعادة المعالجة إلى آثار جانبية.
التبعيات الخارجية: حدود/مهلات محدودة، عدم توفر واجهة برمجة التطبيقات.
البيانات: فساد الحمولة، ترميز غير صحيح، حجم كبير.

2) معايير تقديم DLQ

• تجاوزت الحد الأقصى محاولات المعالجة لدى المستهلك/العامل.
• يتم تصنيف الخطأ على أنه غير قابل للتجربة: مخطط غير صالح، وعدم وجود مورد مهم، وحظر الأعمال.
• انتهت صلاحية رسالة الموعد النهائي (TTL/انتهاء الصلاحية).
• تم تشغيل قاطع الدائرة أو سياسة التحكم في القبول لهذا المفتاح/المستأجر.
• حل المشغل الصريح ("exect' اليدوي من الخيط الرئيسي).

3) طوبولوجيات وأنماط DLQ

لكل قائمة انتظار DLQ: لكل قائمة انتظار/موضوع DLQ خاص به. بسيطة وشفافة.
Central DLQ (ساحة انتظار السيارات): «موقف سيارات» عام للحالات المعقدة، مناسب لأدوات التحليل الموحدة.
DLT (Dead Letter Topic): للحافلات الموجهة نحو تسجيل الدخول (سجل الأحداث) - موضوع منفصل به بيانات وصفية لسبب الفشل.
الحجر الصحي: الحجر الصحي المؤقت مع الوصول الصعب والصرف الصحي PII للتحليل اليدوي.
دفق الظل: تكرار الرسائل الإشكالية في «ظل» لتجارب تثبيت آمنة.

4) البيانات الوصفية المطلوبة لمرافقة DLQ

• سبب الفشل: رمز خطأ/فئة، مكدس/معرف تتبع.
• سياق إعادة: «محاولة»، «محاولات قصوى»، «أول _ شوهد _ ts'،» آخر _ محاولة _ ts'.
• الارتباط: «trace _ id»، «span _ id»، «المستأجر _ id»، «الكيان _ id»، مفتاح التقسيم.
• التعويض الأصلي/التقسيم/التسلسل (لحافلات السجل) أو معرف الرسالة.
• نسخة العقد/المخطط/الحمولة.
• Idempotency-key/Request-id (إن وجد).
• مصدر التوجيه: اسم قائمة الانتظار/الموضوع، مجموعة المستهلكين.

5) إعادة السياسات قبل DLQ

• إعادة تشغيل المستهلك القصير: «المحاولات القصوى» 2-5، التراجع الأسي + النرجس، الحدود القصوى للتزامن.
• الضغط الخلفي التعاوني: تقليل المنافسة مع نمو الأخطاء.
• تصنيف الخطأ: قابل للإعادة («5xx»، المهلة) مقابل غير قابل للإعادة (التحقق، عدم تطابق المخطط).
• طوابير التأخير: 5s → 30s → 2m للإخفاقات المؤقتة.
• العزلة لكل مفتاح: إذا كان المفتاح المحدد «صاخبًا»، فلا تمنع الحزب بأكمله.

6) Safe Redrive (إعادة التسليم من DLQ)

Redrive هو الإرجاع الخاضع للرقابة للرسائل من DLQ إلى المعالجة.

1. إصلاح التحقق: إعادة رسم فقط بعد تثبيت رمز/تكوين/مخطط أو بعد استعادة التبعيات الخارجية.

2. الخصوصية: يجب أن يكون المتعاملون مقاومين للتكرار (عمليات مضطربة ومؤثرة).

3. التفريغ بواسطة «ideputency _ key »/« message _ id »/« business _ key».

4. الدفع والنوافذ: دفعات بواسطة رسائل N، حد السعر عن طريق إعادة التوليد، «النوافذ» حسب الوقت/الأطراف.

5. التحقق المحلي: التحقق السريع من المخطط قبل إعادة الرسم (رفض الحالات الباطلة المبكرة).

6. الأولوية: يجب ألا تحل إعادة الازدهار محل حركة المبيعات (الأولوية المنخفضة للعمال/تجمع الأفراد).

7. إمكانية الرصد: مقاييس ومسارات فردية لإعادة التوليد ؛ تقرير النتائج (النجاح/تكرار DLQ/الخسارة).

7) دلالات التسليم والطلب

مرة واحدة على الأقل هي الطريقة الأكثر شيوعًا: مطلوب الإفراط والتفريغ.
في آن واحد - يمكن تعطيل DLQ ؛ خطر الخسارة. لا تستخدم إلا عندما تكون الخسائر مقبولة.
مرة واحدة بالضبط (فعالة): تتحقق من خلال المعاملات والتفريغ في تخزين الأعمال التجارية ؛ مكلفة ومحددة.
الطلب: عادةً ما يكسر DLQ طلب مفتاح/طرف معين. إذا كان الترتيب حاسمًا، أعد رسمه حسب المفتاح وبالتتابع.

8) المخططات والعقود والتصديق

سجل/عقود المخطط: نسخ واضحة، تطور مع التوافق الخلفي/الأمامي.
التحقق عند المدخل: شيك رخيص من خلال JSON Schema/Protobuf/Avro قبل الخطوات الثقيلة.
سياسة عدم التوافق: مع مجال «كسر» - على الفور في DLQ مع رمز «مخطط _ غير متوافق».
تنقيح PII: قم بتخزين ما تحتاجه فقط في DLQ ؛ قناع الحقول الحساسة.

9) الخصوصية والتفريط

Idempotency-key: form on the producter from «business sense» (المستأجر + الكيان + التشغيل + ts-buket).
سجلات Deadup: احتفظ بالمفاتيح «N» الأخيرة باستخدام TTL ؛ تذكر «تأثير» العملية.
Upsert/الدمج: تجنب «إدخال فقط» دون قيود.
الآثار الجانبية: للمكالمات الخارجية - سجل وفحص «كرر» قبل الاتصال.

10) إمكانية الرصد و SLO

• معدل DLQ (msg/s)، نسبة الرسائل، متوسط/متوسط «العمر» في DLQ.
• نجاح إعادة السحب (٪)، حصة DLQ المتكررة.
• تصنيف الأسباب: مخطط، التحقق، المهلة، التبعية، غير معروف.
• p95/p99 زمن انتقال العلاج السائد مقابل إعادة الازدهار.
• حجم DLQ، خطر الفائض.

• العلامات المطلوبة هي "رسالة _ معرف"، "كيان _ معرف"، "مستأجر _ معرف"، "محاولة"، "سبب"، "redrive _ batch _ id'.
• تتبع «فرع DLQ»: من المصدر إلى النجاح المتكرر.

• النسبة المئوية للرسائل التي تمت معالجتها بنجاح ≥ X٪ في دقائق T.
• وقت التحقيق والتصحيح لقضية DLQ ≤ الساعات Y.
• الحد الأقصى «لعمر» الرسالة في DLQ ≤ Z ساعة (مع تنبيه).

11) السلامة والامتثال

الوصول الأقل امتيازًا: Redrive - المشغلون/كتب اللعب فقط.
مراجعة الحسابات: من ومتى أطلقت البيانات الوصفية المتعلقة بإعادة التوسيع/الحذف/التحرير.
الصرف الصحي: عند الانتقال إلى DLQ المركزي، قم بإزالة PII/الأسرار غير الضرورية.
الاحتفاظ: سياسات منفصلة للاحتفاظ بالمبالغ والحذف فيما يتعلق بالمبالغ المستحقة الدفع.

12) تعدد الإيجارات

مستأجر العلامات - معرف/خطة: تميز الحدود، وتعيد صياغة الأولويات، والتقارير.
لكل مستأجر DLQ أو الحفلات: بحيث لا يسد العميل «الصاخب» إجمالي DLQ.
الفواتير/الحصص: تأخذ في الاعتبار حجم DLQ وتكلفة إعادة الاستخدام.

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) كتيبات التشغيل (كتيبات التشغيل)

1. نمو DLQ غير الطبيعي: تشغيل خنق مستهلك الإنتاج، وتحليل الأسباب الرئيسية، والتحقق من الإصدارات/المخططات.
2. عدم تطابق المخطط: مخطط التراجع/الالتزام، هجرة التكيف، إعادة التوليد بعد التحقق.
3. التبعية الخارجية غير متوفرة: إعادة التدريب المؤقت، وتمكين طابور التأخير، وإعادة التوليد بعد التعافي.
4. DLQs المتكررة بعد إعادة التوليد: تمكين معالج/محاكي «الظل»، تحقق من الخصوصية، دفعة ضيقة.
5. فائض DLQ: الإخلاء إلى الأرشيف والتخزين، وتمكين إعادة الدفع الانتقائي للمفاتيح/الأسباب.

15) الاختبار والفوضى

حقن الخطأ: استراحة المخطط، التحقق من الصحة، المهلة، 1-on-N الأخطاء اللزجة.

مراجعة شاملة: التحقق من الجرعات والتأثير على الإنتاج

التسلسل خارج الترتيب: تأكد من التعامل الصحيح مع المفتاح.
فساد الحمولة: التحقق والفشل الآمن.
التعافي بعد سقوط العامل المعاد: فراغ عمليات الدفعات.

16) أخطاء نموذجية

عدم وجود بيانات وصفية في DLQ → من المستحيل تجميع الأسباب وتعديلها بأمان.
إعادة رسم الكتلة دون حدود → إعادة تدهور الإنتاج.
لا يوجد ازدواجية/تكرار → والآثار الجانبية.
اختلاط PII في وسط DLQ بدون الصرف الصحي.
عدم وجود مخططات/عقود → «مفاجآت» في تطور الرسائل.
DLQ المشترك الوحيد بدون تقسيم المستأجر/المفتاح.
يعيد تشغيل Infinite بدلاً من DLQ المبكر للأخطاء غير القابلة للتجربة.

17) وصفات سريعة

التدفق العادي للأعمال: 3-4 محاولات، التراجع الأسي مع النبضات، التصنيف المبكر للأخطاء، DLQ مع البيانات الوصفية الكاملة.
الأحداث الحرجة (الدفع): الإفراط الصارم، والإجازات القصيرة، والحد الأدنى من المحاولات، و DLQ السريع والتحليل اليدوي.
إعادة رسم الكتلة بعد الإصلاح: دفعات صغيرة (100-500)، حد السعر، مجموعة منفصلة من العمال، مراقبة النجاح> 95٪ قبل زيادة السرعة.
متعدد المستأجر: حدود إعادة التوليد لكل مستأجر، تقرير مولد العملاء الأعلى في DLQ.

استنتاج

DLQ ليست «سلة مهملات»، ولكنها حلقة موثوقية متحكم فيها. قواعد الضربة الواضحة، والبيانات الوصفية الغنية، والخصوصية والتفريغ، والنمو الأحمر الآمن، وانضباط المخطط وقابلية الملاحظة، تحول الرسائل السامة من تهديد لـ SLO إلى عملية هندسية يمكن التحكم فيها - مع كتب لعب مفهومة وتكاليف يمكن التنبؤ بها وتأثير ضئيل على المستخدمين.