Dead-letter queue, qisqacha DLQ — asosiy queue yoki subscriptionda odatiy tartibda qayta ishlanmagan xabarlar yuboriladigan alohida navbatdir. Xabar retry limiti tugashi, consumer uni rad etishi, TTL o‘tishi yoki queue siyosati sabab dead-letter bo‘lishi mumkin. DLQ xatoni yo‘q qilmaydi; uni asosiy oqimni to‘smasdan saqlash va tekshirish imkonini beradi.
Dead-letter sabablari
RabbitMQda consumer reject yoki nackni requeue=false bilan yuborsa, message TTL tugasa yoki queue length limitdan oshsa xabar dead-letter exchangega yo‘naltirilishi mumkin. Broker va xizmatga qarab sabablar farq qiladi. Kafka ekotizimida DLQ ko‘pincha consumer ilovasi boshqa topicga publish qiladigan pattern bo‘lib, brokerning universal xususiyati emas.
Dead-letter metadata original destination, sabab, urinish soni va vaqtni saqlashi kerak. Faqat payloadni ko‘chirish diagnostika kontekstini yo‘qotadi. Shu bilan birga header har qayta yo‘naltirishda cheksiz o‘smasligi nazorat qilinadi.
Retry bilan munosabat
Vaqtinchalik xato uchun darhol DLQga yuborish xabarni keragidan erta ajratadi. Cheksiz tez retry esa broker va dependencyga yuk beradi. Odatda exponential backoff, maksimal urinish va xato klassifikatsiyasi qo‘llanadi. Invalid schema kabi doimiy xato retry qilinmasdan ajratilishi mumkin.
Delayed retry alohida retry queuelari, scheduled delivery yoki consumer scheduler bilan bajariladi. Retry paytida original tartib buzilishi mumkin. Bir entity eventlari qat’iy ketma-ket bo‘lsa keyingi xabarlarni davom ettirish domen holatini buzishi ehtimol.
Tahlil va qayta ijro
DLQ operator ko‘rmaydigan “qabriston” bo‘lmasligi kerak. Queue depth, eng eski xabar yoshi, sabab va producer version bo‘yicha alert yaratiladi. Payload schema validator, stack trace va correlation ID root causeni topishga yordam beradi.
Tuzatishdan so‘ng replay nazoratli amalga oshiriladi. Xabar idempotent consumerga yuboriladi, rate limit bilan asosiy tizim bosilmaydi va yana xato bo‘lsa yangi urinish tarixi saqlanadi. Barcha DLQni ko‘r-ko‘rona asosiy queuega qaytarish incidentni takrorlashi mumkin.
Saqlash va xavfsizlik
DLQ retention va maksimal hajmga ega. Cheksiz saqlash diskni to‘ldiradi, juda qisqa retention esa tekshiruvdan oldin dalilni yo‘qotadi. Sezgir payload asosiy queue bilan bir xil yoki kuchliroq access control va encryption talab qiladi.
DLQga read huquqi ko‘pincha production ma’lumotini ko‘rish imkonini beradi. Replay uchun write huquqi undan ham xavfli, chunki eski moliyaviy yoki notification amalni qayta bajarishi mumkin. Operator amallari audit qilinadi.
Arxitektura chegarasi
Har consumer uchun alohida DLQ ownershipni aniq qiladi; umumiy DLQ markaziy kuzatuvni soddalashtiradi, lekin turli schema va ruxsatlarni aralashtiradi. Tanlov xizmatlar soni, data tasnifi va replay jarayoniga bog‘liq.
DLQ success metric emas. Xabar yo‘qolmagani bilan foydalanuvchi amali bajarilmagan bo‘ladi. SLO va biznes monitoring DLQga tushgan muhim xabarni failure sifatida hisoblaydi.
Original xabar yaxlitligi
Dead-letter jarayonida payloadni diagnostika uchun tahrirlash original dalilni yo‘qotadi. Xato tavsifi va retry metadata alohida envelope yoki headerga qo‘shiladi. Payload checksum replaydan oldin buzilmaganini tekshiradi. Agar maxfiy maydonni DLQda saqlash mumkin bo‘lmasa, tokenized nusxa va himoyalangan original storage o‘rtasida reference ishlatiladi.
Replay tool yangi correlation ID yaratishi, lekin original message IDni ham saqlashi kerak. Aks holda consumer deduplicationi qayta ishlashni bloklashi yoki kuzatuv zanjiri uzilishi mumkin. Replay operatori qaysi consumer versiyasi xabarni olishini biladi.
Bog‘liq tushunchalar
Message queue, Retry, Poison message, Negative acknowledgement, Message TTL, Replay, Idempotency