每個(gè)數(shù)據(jù)處理系統(tǒng)都會(huì)遇到搞不定的記錄。字段缺失、類(lèi)型異常、體積超標(biāo)，或者下游服務(wù)直接甩來(lái)一個(gè)非臨時(shí)性錯(cuò)誤。這時(shí)候怎么處理這條記錄，決定了你的系統(tǒng)是"能用"還是"可靠"。

死信隊(duì)列（DLQ，Dead Letter Queue）就是用來(lái)兜底的機(jī)制。它不會(huì)讓系統(tǒng)無(wú)限重試，也不會(huì)悄悄把失敗記錄扔掉，而是把這條"死信"寫(xiě)進(jìn)專(zhuān)門(mén)隊(duì)列，然后繼續(xù)處理下一條。

這篇指南講清楚：DLQ里該存什么、怎么實(shí)現(xiàn)、什么時(shí)候用、怎么監(jiān)控。

一條DLQ記錄至少要能回答三個(gè)問(wèn)題：原始數(shù)據(jù)什么樣、在哪一步失敗、為什么失敗。所以最低限度要包含：完整原始載荷（不能只存引用，因?yàn)樵磾?shù)據(jù)可能已變或刪除）、錯(cuò)誤信息、失敗階段、時(shí)間戳、重試次數(shù)。

存儲(chǔ)方式看架構(gòu)。消息隊(duì)列型：RabbitMQ原生支持死信交換，超重試次數(shù)或超時(shí)的消息自動(dòng)路由到DLQ；Kafka沒(méi)有原生DLQ，標(biāo)準(zhǔn)做法是寫(xiě)到專(zhuān)用主題（慣例命名-dlq），失敗元數(shù)據(jù)放消息頭。數(shù)據(jù)庫(kù)型：?jiǎn)伍_(kāi)一張表，字段包括原始記錄JSON、錯(cuò)誤信息、階段、時(shí)間戳、失敗次數(shù)，給階段和時(shí)間戳加索引方便查詢(xún)。云托管隊(duì)列：Amazon SQS內(nèi)置DLQ，通過(guò)redrive策略配置最大接收次數(shù)和目標(biāo)隊(duì)列；Google Cloud Pub/Sub也有類(lèi)似死信策略。

處理流程的標(biāo)準(zhǔn)模式是固定重試次數(shù)后進(jìn)DLQ。代碼結(jié)構(gòu)大概這樣：定義MAX_RETRIES=3，處理時(shí)捕獲異常，如果是臨時(shí)錯(cuò)誤（網(wǎng)絡(luò)超時(shí)、限流、服務(wù)短暫不可用）且未超重試次數(shù)，就退避重試；超次數(shù)則寫(xiě)DLQ。如果是永久錯(cuò)誤（校驗(yàn)失敗、類(lèi)型錯(cuò)誤、業(yè)務(wù)邏輯不通過(guò)），直接進(jìn)DLQ，不重試。

區(qū)分臨時(shí)錯(cuò)誤和永久錯(cuò)誤是關(guān)鍵。前者值得等一等再試，后者試再多次也沒(méi)用。