每个数据处理系统都会遇到搞不定的记录。字段缺失、类型异常、体积超标,或者下游服务直接甩来一个非临时性错误。这时候怎么处理这条记录,决定了你的系统是"能用"还是"可靠"。
死信队列(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.