DLQ და შხამიანი შეტყობინებების დამუშავება

Dead Letter Queue (DLQ) არის იზოლირებული ხაზი/ტოპიკი შეტყობინებებისთვის, რომლებიც ვერ მოხერხდა სტანდარტული კონსიუმერის დამუშავება მოცემული რაოდენობის მცდელობების შემდეგ ან აშკარა ტექნიკური/საქმიანი მიზეზების გამო (შეუსაბამო სქემა, ტაიმუთი, ვერსიების კონფლიქტი და ა.შ.). შხამიანი მესიჯი (poison მესიჯი) - ჩანაწერი, რომლის განმეორებითი დამუშავება მუდმივად მთავრდება შეცდომით და საფრთხეს უქმნის paypline- ის სტაბილურობას.

DLQ- ის მიზანი: SLO- ს შენარჩუნება, მარცხის ლოკალიზაცია, ძირითადი ნაკადის დაბლოკვის თავიდან აცილება და ანალიზისა და უსაფრთხო ხელახალი რეპროდუქციის შესაძლებლობის გარანტია (redrive).

1) საიდან მოდის შხამიანი შეტყობინებები

სქემები/კონტრაქტები: შეუთავსებელი ცვლილებები, არ არსებობს სავალდებულო ველები, არასწორი ტიპები.
ბიზნესის ვალდებულება: დუბლიკატები, დარღვეული ინვარიანტები, ვადაგასული მოვლენები.
ბრძანება და მიზეზი: „განახლება“ მოვიდა „Create“ - ში, გამოტოვებული კორელაციები, out-of-order.
Idempotence: განმეორებითი დამუშავება იწვევს გვერდითი მოვლენებს.
გარე დამოკიდებულება: შეზღუდული ლიმიტები/ტაიმაუტები, API- ს მიუწვდომლობა.
მონაცემები: დატვირთვის კორუფცია, არასწორი კოდირება, ზომების გადაჭარბება.

2) DLQ- ში გაგზავნის კრიტერიუმები

• გადააჭარბა MaxAttempts დამუშავებას Consumer/Worker.
• შეცდომა კლასიფიცირდება, როგორც გაუმართავი (არაკომერციული): შეუსაბამო სქემა, კრიტიკული რესურსის არარსებობა, ბიზნესის აკრძალვა.
• Deadline შეტყობინებები (TTL/expiration).
• Circuit breaker- ის ან admission Controll- ის პოლიტიკა ამ გასაღების/ტენანტისთვის მუშაობდა.
• ოპერატორის აშკარა გადაწყვეტა (სახელმძღვანელო „პროექტი“ მთავარი ნაკადიდან).

3) ტოპოლოგია და DLQ ნიმუშები

Per-queue DLQ: თითოეულ რიგს/ტოპიკას აქვს საკუთარი DLQ. უბრალოდ და გამჭვირვალე.
ცენტრალური DLQ: ზოგადი „პარკინგი“ რთული შემთხვევებისთვის, მოსახერხებელია ერთი ანალიზის ინსტრუმენტებისთვის.
DLT (Dead Letter Topic): ლოგზე ორიენტირებული საბურავისთვის (event log) - ცალკეული ტოპიკი, მეტამონაცემებით უარის თქმის მიზეზებით.
Quarantine: საკარანტინო ბუფერი მკაცრი დაშვებით და ხელით ანალიზისთვის PII მოწესრიგება.
Shadow-stream: პრობლემური შეტყობინებების დუბლირება „ჩრდილში“ უსაფრთხო ფიქსირებული ექსპერიმენტებისთვის.

4) მეტამონაცემები, რომლებსაც თან ახლავს DLQ

• უარის თქმის მიზეზი: შეცდომის კოდი/კლასი, შეტევა/ტრეკი id.
• განმეორების კონტექსტი: 'attempt', 'maxAttempts', 'first _ seen _ ts', 'last _ attempt _ ts'.
• კორელაცია: 'trace _ id', 'span _ id', 'tenant _ id', 'entity _ id', განაწილების გასაღები.
• ორიგინალური offset/წვეულება/sequence (დენის საბურავებისთვის) ან შეტყობინებების id.
• კონტრაქტი/სქემა/დატვირთვის ვერსია.
• Idempotency-key/Request-id (თუ არსებობს).
• მარშრუტიზაციის წყარო: რიგის/ტოპიკის სახელი, კონსუმერული ჯგუფი.

5) რეაგირების პოლიტიკა DLQ- მდე

• Consumer- ის მოკლე შენიშვნები: 'maxAttempts' 2-5, exponential backoff + gitter, caps concurrency.
• კოოპერატივის backpressure: შეცდომების ზრდის დროს კონკურენციის შემცირება.
• შეცდომების კლასიფიკაცია: retryable ('5xx', ტაიმუთი) vs non-retryable (სავალდებულო, schema mismatch).
• გადავადებული ხაზები: 5s-30s-2m დროებითი შეფერხებისთვის.
• Per-key იზოლაცია: თუ კონკრეტული გასაღები „ხმაურიანია“, არ დაბლოკოთ მთელი პარტიის.

6) უსაფრთხო რადარი (განმეორებითი მიწოდება DLQ- დან)

Redrive არის კონტროლირებადი შეტყობინებების დაბრუნება DLQ- დან დამუშავებაში.

1. ფიქსაციის შემოწმება: რედრივი მხოლოდ კოდის/კონფიგურაციის/სქემის კორექტირების შემდეგ ან გარე დამოკიდებულების აღდგენის შემდეგ.

2. Idempotention: გამტარებლები უნდა იყვნენ გამძლე გამეორებისთვის (upsert, ეფექტის ტოლერანტული ოპერაციები).

3. დედუპლიკაცია: 'idempotency _ key '/' მესიჯი _ id '/' business _ key ".

4. დოზა და ფანჯრები: Batches on N შეტყობინებები, redrive rate-limit, „windows“ დროულად/წვეულებებზე.

5. ადგილობრივი შესაბამისობა: სქემის სწრაფი შემოწმება რედრეივამდე (ადრეული დაუცველი შემთხვევების ანგარიში).

6. პრიორიტეტი: რედრივმა არ უნდა შეცვალოს გაყიდვების ტრაფიკი (ვორკერების დაბალი პრიორიტეტი/ცალკეული აუზები).

7. დაკვირვება: ცალკეული მეტრიკა და ტრეისი რედრეივისთვის; ანგარიშის შედეგები (წარმატება/განმეორებითი DLQ/ზარალი).

7) მიწოდების სემანტიკა და წესრიგი

At-least-once ყველაზე ხშირი რეჟიმია: საჭიროა იდემპოტენტობა და დედაპლიკაცია.
At-most-once - DLQ შეიძლება გამორთული იყოს; ზარალის რისკი. გამოიყენეთ მხოლოდ დასაშვები დანაკარგებით.
Exactly-once (ეფექტური): მიიღწევა გარიგებებით და ბიზნეს საცავში ბაბუით; ძვირი და სპეციფიკური.
შეკვეთა: DLQ ჩვეულებრივ იშლება კონკრეტული გასაღების/ნაწილისთვის. თუ ბრძანება კრიტიკულია, წაშალეთ გასაღები და თანმიმდევრულად.

8) სქემები, კონტრაქტები და შესაბამისობა

Schema registry/კონტრაქტები: მკაფიო ვერსია, ევოლუცია backward/forward თავსებადობით.
მისაბმელი შესასვლელი: იაფი შემოწმება JSON Schema/Protobuf/Avro- ს მეშვეობით მძიმე ნაბიჯების წინ.
შეუთავსებლობის პოლიტიკა: „გატეხილი“ ველში - დაუყოვნებლივ DLQ- ში კოდით „SCHEMA _ INCOMPATIBLE“.
Redaction PII: DLQ- ში შეინახეთ მხოლოდ საჭირო; მგრძნობიარე ველები შენიღბეთ.

9) Idempotence და deduplication

Idempotency-key: შექმნათ tenant + entity + operation + ts-bucket მწარმოებელზე.
დედოპის ჟურნალები: შეინახეთ უახლესი 'N' გასაღებები TTL- ით; დაიმახსოვრე ოპერაციის „ეფექტი“.
Upsert/merge: თავიდან აიცილეთ „insert-only“ შეზღუდვების გარეშე.
გვერდითი ეფექტები: გარე გამოწვევებისთვის - დაათვალიერეთ და შეამოწმეთ „გამეორება“ გამოწვევამდე.

10) დაკვირვება და SLO

• DLQ rate (msg/s), შეტყობინებების წილი, საშუალო/საშუალო „ასაკი“ DLQ- ში.
• Redrive (%) წარმატება, განმეორებითი DLQ წილი.
• მიზეზების კლასიფიკაცია: schema, validation, timeout, dependence, unknown.
• p95/p99 redrive- ში ძირითადი ნაკადის დამუშავების ლატენტობა.
• DLQ ზომა, გადინების რისკი.

• სავალდებულო ჭდეები: 'მესიჯები _ id', 'entity _ id', 'tenant _ id', 'attempt', 'reason', 'redrive _ batch _ id'.
• DLQ ფილიალის კვალი: წყაროდან მეორე წარმატებამდე.

• წარმატებით დამუშავებული შეტყობინებების წილი X% -ია T წუთში.
• DLQ შემთხვევისთვის გამოძიებისა და კორექტირების დრო საათია.
• შეტყობინებების მაქსიმალური „ასაკი“ DLQ-Z საათებში (ალერტით).

11) უსაფრთხოება და შესაბამისობა

მინიმალური შეღავათების პრინციპზე წვდომა: რედრივი - მხოლოდ ოპერატორები/ფლეიბუკები.
აუდიტი: ვინ და როდის გამოხატა მეტამონაცემების რედაქცია/მოცილება/რედაქტირება.
მოწესრიგება: ცენტრალურ DLQ- ში გადატანისას ამოიღეთ დამატებითი PII/საიდუმლოებები.
Retention: ინდივიდუალური შენახვის დრო და წაშლის პოლიტიკა DLQ- სთვის.

12) მულტფილმი-ტენანტობა

ჭდეები 'tenant _ id/plan': განასხვავეთ limites, redrive პრიორიტეტები, მოხსენებები.
პერ-ჩრდილოვანი 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) runbooks

1. DLQ- ის არანორმალური ზრდა: ჩართეთ throttling prod კონსიუმერი, გაანალიზეთ ტოპ მიზეზები, შეამოწმეთ გამოშვებები/სქემები.
2. Schema mismatch: გამოტოვება/სქემის ფიქსაცია, ადაპტერის მიგრაცია, გადამოწმების შემდეგ redrive.
3. გარეგანი დამოკიდებულება მიუწვდომელია: retrai- ს პაუზა, delay რიგის ჩართვა, აღდგენის შემდეგ redrive.
4. განმეორებითი DLQ რედაქციის შემდეგ: ჩართეთ „ჩრდილის“ დამუშავება/სიმულატორი, შეამოწმეთ idempotence, შეამციროთ batch.
5. DLQ- ის გადინება: არქივის სცენაზე ევაკუაცია, შერჩევითი რელიეფის ჩართვა კლავიშების/მიზეზების გამო.

15) ტესტირება და ქაოსი

შეცდომების ინექცია: schema-break, შესაბამისობა, ტაიმაუტები, 1-on-N „წებოვანი“ შეცდომები.
მასობრივი რადარი: დოზის შემოწმება და პროდზე გავლენის მოხდენა.
Out-of-order თანმიმდევრობა: ensure სწორი დამუშავება კლავიშებზე.
დატვირთვის კორუფცია: რეალური და უსაფრთხო უარი.
რედრივის ვორკერის დაცემის შემდეგ აღდგენა: batch ოპერაციების იდემპოტენტურობა.

16) ტიპიური შეცდომები

DLQ- ში მეტამონაცემების არარსებობა შეუძლებელია მიზეზების კლასიფიცირება და უსაფრთხოდ რელიეფის გაკეთება.
მასობრივი რედრიდი ლიმიტების გარეშე - წარმოების განმეორებითი დეგრადაცია.
არ არსებობს იდემპოტენტურობა/ბაბუა, დუბლი და გვერდითი მოვლენები.
PII შერევა ცენტრალურ DLQ- ში შეკვეთის გარეშე.
სქემების/კონტრაქტების არარსებობა არის „სიურპრიზი“ შეტყობინებების ევოლუციის დროს.
ერთადერთი ზოგადი DLQ ტენიანობის/გასაღების გარეშე.
გაუთავებელი ჭრილობები ადრეული DLQ- ის ნაცვლად არაკონტროლირებადი შეცდომებისთვის.

17) სწრაფი რეცეპტები

ჩვეულებრივი ბიზნეს ნაკადი: 3-4 მცდელობა, ექსპონენციალური ჯიტერი, შეცდომების ადრეული კლასიფიკაცია, DLQ სრული მეტამონაცემებით.
კრიტიკული მოვლენები (გადახდა): მკაცრი იდემპოტენტობა, მოკლე ტაიმუტი, მინიმალური მცდელობები, სწრაფი DLQ და სახელმძღვანელო ანალიზი.
მასობრივი რადარი ფაქსის შემდეგ: მცირე ზომის ბუჩქები (100-500), საბურღი-ლიმიტი, ცალკეული ვორკერების აუზი, წარმატების მონიტორინგი> 95% სიჩქარის გაზრდამდე.
მრავალ ტენანტი: პრე-ტენანტური შეზღუდვები რედაქციისთვის, მოხსენება DLQ- ის გენერატორების ტოპ მომხმარებლებზე.

დასკვნა

DLQ არ არის „ნაგვის კალათა“, არამედ კონტროლირებადი საიმედოობის წრე. ჰიტების მკაფიო წესები, მდიდარი მეტამონაცემები, impotence და დედუპლიკაცია, უსაფრთხო დოზირებული რელიეფი, სქემების დისციპლინა და დაკვირვება შხამიანი შეტყობინებები საფრთხისგან SLO- ს კონტროლირებად საინჟინრო პროცესად აქცევს - გასაგები პლეიბუკებით, პროგნოზირებული ხარჯებით და მომხმარებლებზე მინიმალური გავლენით.