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

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

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

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

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

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

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