北京
每个数据处理系统都会遇到搞不定的记录。字段缺失、类型异常、体积超标，或者下游服务直接甩来一个非临时性错误。这时候怎么处理这条记录，决定了你的系统是"能用"还是"可靠"。
死信队列（DLQ，Dead Letter Queue）就是用来兜底的机制。它不会让系统无限重试，也不会悄悄把失败记录扔掉，而是把这条"死信"写进专门队列，然后继续处理下一条。
这篇指南讲清楚：DLQ里该存什么、怎么实现、什么时候用、怎么监控。
一条DLQ记录至少要能回答三个问题：原始数据什么样、在哪一步失败、为什么失败。所以最低限度要包含：完整原始载荷（不能只存引用，因为源数据可能已变或删除）、错误信息、失败阶段、时间戳、重试次数。
存储方式看架构。消息队列型：RabbitMQ原生支持死信交换，超重试次数或超时的消息自动路由到DLQ；Kafka没有原生DLQ，标准做法是写到专用主题（惯例命名-dlq），失败元数据放消息头。数据库型：单开一张表，字段包括原始记录JSON、错误信息、阶段、时间戳、失败次数，给阶段和时间戳加索引方便查询。云托管队列：Amazon SQS内置DLQ，通过redrive策略配置最大接收次数和目标队列；Google Cloud Pub/Sub也有类似死信策略。
处理流程的标准模式是固定重试次数后进DLQ。代码结构大概这样：定义MAX_RETRIES=3，处理时捕获异常，如果是临时错误（网络超时、限流、服务短暂不可用）且未超重试次数，就退避重试；超次数则写DLQ。如果是永久错误（校验失败、类型错误、业务逻辑不通过），直接进DLQ，不重试。
区分临时错误和永久错误是关键。前者值得等一等再试，后者试再多次也没用。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
