DLQ וטיפול בהודעות רעל

תור אותיות מתות (באנגלית: Dead Letter Queue או DLQ) הוא תור/נושא מבודד עבור הודעות שלא ניתן היה לעבד על ידי צרכן רגיל לאחר מספר ניסיונות או מסיבות טכניות/עסקיות ברורות (סכימה לא תקפה, פסק זמן, קונפליקט גרסאות וכו '). מסר רעיל - תיעוד שהעיבוד מחדש שלו נכשל באופן עקבי ומאיים על יציבות הצינור.

מטרת DLQ היא לשמר את SLO, לאתר את הכישלון, למנוע חסימה של הזרם הראשי ולהבטיח את האפשרות לניתוח ושידור חוזר בטוח (redrave).

1) מהיכן מגיעות הודעות ארסיות

סכמות/חוזים: שינויים לא מתאימים, שדות חסרים, סוגים לא נכונים.
אימות עסקי: כפילויות, הפרת אינווריאנטים, אירועים פגו.
סדר וסיבתיות: הגיע ”עדכון” ל ”צור”, התאמות חסרות, מחוץ לסדר.
אידמפוטנטיות: עיבוד מחדש יוצר תופעות לוואי.
תלות חיצונית: מגבלות/פסקי זמן מוגבלים, אי-זמינות של API.
נתונים: שחיתות מטען, קידוד שגוי, גודל יתר.

2) קריטריון הגשת DLQ

• חרג מהניסיונות לעיבוד אצל הצרכן/עובד.
• השגיאה מסווגת כבלתי ניתנת לניסוי: תרמית לא תקפה, היעדר משאב קריטי, איסור עסקי.
• פג תוקף הודעת המועד האחרון (TTL/פקיעה).
• מפסק המעגל או מדיניות בקרת הכניסה הופעלה עבור מפתח/דייר זה.
• פתרון אופרטור מפורש (”להוציא” מדריך מהחוט הראשי).

3) טופולוגיות ותבניות DLQ

פר תור DLQ: לכל תור/נושא יש DLQ משלו. פשוט ושקוף.
מרכז DLQ (חניון): ”חניה” כללית עבור מקרים מורכבים, נוח עבור כלי ניתוח מאוחדים.
DLT (Toptice Dead Letter): עבור אוטובוסים מונחי יומן אירועים - נושא נפרד עם מטא-נתונים של הסיבה לכישלון.
חוצץ הסגר עם גישה קשה ותברואה של מח "ש לניתוח ידני.
שכפול של מסרים בעייתיים לתוך ”צל” לניסויי קיבעון מאובטחים.

4) Metadata נדרש ללוות DLQ

• סיבה לכישלון: קוד שגיאה/מחלקה, ערמה/עקבות id.
• הקשר Retray: 'ניסיון', 'MaxEnverses', 'first _ see _ ts',' last _ truse _ ts'.
• קורלציה: "trace _ id", "span _ id'," terant _ id', "unty _ id', מפתח החלוקה.
• קיזוז/מחיצה/רצף מקורי (עבור רישום אוטובוסים) או זיהוי הודעה.
• חוזה/סכימה/גרסת המטען.
• Idempotency-key/Request-id (אם בכלל).
• מקור ניתוב: שם תור/נושא, קבוצת צרכנים.

5) מדיניות מגש מחדש לפני DLQ

• מגשים צרכניים קצרים: "MaxNersons' 2-5, גיבוי מעריכי + jitter, כובע על קונקורנסי.
• תרמיל גב קואופרטיבי: הפחתת התחרות ככל ששגיאות גדלות.
• סיווג שגיאה: ניתן לניסוי מחדש (”5xx”, timeout) vs. non-religinable (אימות, סכימת אי התאמה).
• תור השהייה: 50 אס פי 30. 2 מ 'לכישלונות זמניים.
• בידוד לפי מפתח: אם מפתח מסוים הוא ”רועש”, אל תחסום את כל המפלגה.

6) נסיעה אדומה בטוחה (Redelivery from DLQ)

Redrive היא החזרה מבוקרת של הודעות מ-DLQ לעיבוד.

1. שינוי סימון: שרטוט מחדש רק לאחר תיקון קוד/הגדרות/סכימה או לאחר שחזור תלות חיצונית.

2. Idempotency: מפעילים חייבים להיות עמידים לחזרה (opsert, effect-toluant operations).

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

4. חבורה וחלונות: חבורות על ידי N הודעות, קצב הגבלה על ידי נסיעה מחדש, ”חלונות” על ידי זמן/מסיבות.

5. אימות מקומי: אימות מהיר של התרמית לפני שרטוט מחדש (דחיית מקרים לא תקפים מוקדמים).

6. עדיפות: אין להסיע מחדש את תנועת המכירות (עדיפות נמוכה של מאגר העובדים/הפרט).

7. יכולת תצפית: מדדים אישיים ושבילים לנסיעה מחדש; דו "ח התוצאה (הצלחה/חזרה DLQ/הפסד).

7) משלוח סמנטיקה וסדר

לפחות פעם אחת הוא המצב הנפוץ ביותר: אידמפוטנטיות ושכפול נדרשים.
לכל היותר - ניתן לנטרל את DLQ; סיכון לאובדן. השתמש רק כאשר הפסדים הם מקובלים.
בדיוק-פעם אחת (יעיל): הושג על ידי עסקאות ושכפול באחסון עסקי; יקר וספציפי.
סדר: DLQ בדרך כלל מפר את הסדר עבור מפתח/צד מסוים. אם הסדר הוא קריטי, לצייר מחדש על ידי מפתח ורצוף.

8) מזימות, חוזים ואימות

סכימה רישום/חוזים: ורסינציה ברורה, אבולוציה עם תאימות לאחור/קדימה.
אישור בכניסה: בדיקה זולה דרך JSON Schema/Protobuf/Avro לפני צעדים כבדים.
מדיניות אי-התאמה: עם שדה ”שבירה” - מיד ב-DLQ עם קוד 'SCHEMA _ INSCATIBLE'.
Redaction PII: לאחסן רק את מה שאתה צריך ב DLQ; מסכת שדות רגישים.

9) אידמפוטנטיות ושכפול

Idempotency-key: טופס על המפיק מתוך ”חוש עסקי” (דייר + ישות + פעולה + ts-bucket).
יומני Deadup: שמור את מפתחות ה-N האחרונים עם TTL; זכור את ה ”אפקט” של המבצע.
Upsert/מיזוג: להימנע ”להכניס בלבד” ללא הגבלה.
תופעות לוואי: עבור שיחות חיצוניות - רשום ובדוק ”חזור” לפני השיחה.

10) יכולת תצפית ו ־ SLO

• קצב DLQ (msg/s), פרופורציה של הודעות, ממוצע/גיל חציוני ב DLQ.
• הצלחה של redrave (%), שיתוף DLQ חוזר ונשנה.
• סיווג סיבות: סכימה, אימות, פסק זמן, תלות, לא ידוע.
• p95/p99 טיפול מיינסטרים latency vs בנסיעה מחדש.
• גודל DLQ, סיכון של עודף.

• תגיות נדרשות הן ”הודעה _ id',” ישות _ id', ”דייר _ id',” ניסיון ”,” סיבה ”,” redrive _ batch _ id'.
• התחקות אחר ”סניף DLQ”: ממקור להצלחה חוזרת.

• אחוז ההודעות שעובדו בהצלחה ב ־ X% בדקות T.
• זמן חקירה ותיקון לתיק של די-אל-קיו, שעות עבודה.
• הגיל המקסימלי של ההודעה ב-DLQ (עם התראה).

11) בטיחות וציות

גישה לפחות חיסיון: Redrive - אופרטורים/ספרי משחק בלבד.
ביקורת: מי וכאשר מופעל מחדש/למחוק/לערוך metadata.
תברואה: בעת העברה למרכז DLQ, הסר סודות PII/מיותרים.
שימור: מדיניות שימור ומחיקה נפרדת עבור DLQ.

12) עמידות מרובה

תגיות 'דייר _ id/plan': הבחנה בין גבולות, סדרי עדיפויות, דוחות.
Per-terant DLQ או parties: כך שהלקוח ה ”רועש” אינו סותם את ה-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. סכימה לא תואמת: סכימת rollback/להתחייב, נדידת מתאם, נסיעה מחדש לאחר אימות.
3. תלות חיצונית לא זמינה: עצור מתאמן מחדש, אפשר תור השהייה, נסיעה מחדש לאחר ההחלמה.
4. DLQs חוזר לאחר הנהיגה מחדש: אפשר את הפעלת/סימולטור ”צל”, בדוק idempotency, אצווה צרה.
5. DLQ עולה על גדותיו: פינוי לאחסון ארכיון, אפשרות לשרטט מחדש סלקטיבי עבור מפתחות/סיבות.

15) בדיקה ותוהו ובוהו

הזרקת שגיאה: סכימה-הפסקה, אימות, פסקי זמן, 1-on-N שגיאות דביקות.

שינוי המוני: בדיקת מינון והשפעה על הייצור

רצף מחוץ לסדר: ודא טיפול מפתח נכון.
שחיתות מטען: אימות וכישלון בטוח.
התאוששות לאחר נפילת עובד הנהיגה מחדש: אידמפוטנטיות של פעולות אצווה.

16) שגיאות אופייניות

חוסר metadata ב DLQ = זה בלתי אפשרי לאשכול סיבות ולשנות בבטחה.
שרטוט מחדש המוני ללא מגבלות.
אין אידמפוטנטיות/שכפול = שכפולים ותופעות לוואי.
MII ערבוב במרכז DIQ ללא תברואה.
חוסר בתכניות/חוזים * ”הפתעות” באבולוציה של הודעות.
ה-DLQ הנפוץ היחיד ללא מחיצת דייר/מפתח.
אינסוף מגשים מחדש במקום DLQ מוקדם עבור שגיאות שאינן ניתנות לניסוי.

17) מתכונים מהירים

זרימה עסקית רגילה: 3-4 ניסיונות, גיבוי מעריכי עם ג 'יטר, סיווג מוקדם של שגיאות, DLQ עם metadata מלאה.
אירועים קריטיים (תשלום): אידמפוטנטיות קפדנית, פסקי זמן קצרים, מינימום ניסיונות, DLQ מהיר וניתוחים ידניים.
שרטוט מחדש לאחר תיקון: חבורות קטנות (100-500), מגבלות קצב, בריכה נפרדת של עובדים, ניטור הצלחה> 95% לפני הגדלת המהירות.
רב-דייר: לכל דייר מגבלות נסיעה מחדש, DLQ גנרטור לקוחות עליון.

סיכום

DLQ הוא לא ”פח אשפה”, אלא לולאת אמינות מבוקרת. כללי פגיעה ברורים, מטאדטה עשירה, אידמפוטנטיות ושכפול, נסיעה חוזרת מאומצת מאובטחת, סכימת משמעת ותצפית להפוך מסרים רעילים מאיום ל-SLO לתהליך הנדסי שניתן לניהול - עם ספרי משחק מובנים, עלויות צפויות והשפעה מינימלית על משתמשים.