做订单系统这几年最让我头疼的不是代码写不出来而是消息处理失败之后那一堆“烂摊子”下游库存服务超时订单消息消费失败把它重新塞回队列几秒钟后又被同一个消费者捞起来再处理一遍再失败再塞回——如果没人干预这条消息能在队列里折腾一整天业务日志刷得满屏报错。更烦人的是它还会把排在后面的正常消息一起拖慢消费者线程被它占着整个系统的吞吐量肉眼可见地往下掉。其实问题的根源不在消费者不够努力而在于我们缺少一套“处理不了的消息”的去向机制。RabbitMQ 里恰好提供了对应的基础设施死信队列DLX。这一篇我不打算讲基础概念直接从异常消息的重试阶梯、失败消息归档这两个实战方向展开最后分享几个我在生产环境里踩过的坑。如果你已经会用 RabbitMQ 收发消息但被线上消息失败、堆积甚至丢消息的问题困扰这篇文章应该能给你一个明确的落地方案。1. 为什么说死信队列是消息系统的“故障保险丝”1.1 死信消息到底长什么样死信队列和普通业务队列没有本质区别它同样是一个队列有 exchange、routing key、消费者。唯一的区别在于消息来源普通队列里的消息来自生产者投递死信队列里的消息来自“另一个队列的转存”。当一条消息在队列里被判为死信并被转发时RabbitMQ 会在消息的 headers 里附加一条x-death记录里面包含死信原因、原队列、时间和次数。举个例子x-death: [{ reason: expired, queue: order.pay.timeout.queue, time: 2025-01-12 14:32:01, count: 1 }]reason字段告诉你它为什么变成死信queue字段记录它之前所在的队列名count记录它是第几次因为同样的原因死掉。这些字段不是摆设后面做延迟重试和重试次数控制时全靠它们来判断当前消息已经“折腾”了几轮。1.2 不用死信队列的三种尴尬结局我见过几种不用死信队列的项目结局都比较相似。第一种是无限 requeue。消费者捕获异常后调用 basicNack 并把requeue参数设为 true希望“过一会儿再处理”。但 RabbitMQ 的 requeue 是立即重新投递不是延迟投递所以一条失败消息会以每秒几十次甚至上百次的频率反复进入消费者CPU 被打满日志疯狂刷屏正常消息也跟着遭殃。第二种是直接丢弃消息。代码里 try-catch 吞掉异常然后手动 ack。这个方案表面清净实际上业务已经停留在中间状态——比如“订单已支付但库存没扣成功”而且从 RabbitMQ 管理界面完全看不出曾经出过问题只能翻业务日志慢慢找。第三种是把失败消息全部塞进同一个 retry 队列但没有做延迟分级。消息确实保住了但消费者进程永远在重试同一批坏消息重试队列不断膨胀最后连 RabbitMQ 管理页面的队列列表刷出来都要卡几秒。这种方案本质上是把“处理失败”变成“永远在重试的路上”问题没有真正被受理。死信队列的存在把“失败消息去哪了”这个问题从应用代码层面提升到了队列策略层面。它像消息系统的故障保险丝反正你当前处理不了先给你一个明确的地方存起来再由人或者后续程序决定是重试、归档还是人工介入。2. 死信的三条产生路径与触发参数解析2.1 消息 TTL 过期触发的死信RabbitMQ 的消息过期有两种设置方式一种是声明队列时指定x-message-ttl队列里所有消息超过该时间未消费就会被判定过期另一种是在发布消息时给单条消息设置expiration属性精确控制这一条消息的存活时长。声明的队列参数大致是这样MapString, Object args new HashMap(); args.put(x-message-ttl, 60000); args.put(x-dead-letter-exchange, exchange.dead); args.put(x-dead-letter-routing-key, rk.dead);当队列里的消息过了 60 秒仍未被消费RabbitMQ 会把它转投到你指定的exchange.dead再根据rk.dead路由到死信队列。这里有一个关键认知过期判断是在消息即将被投递给消费者之前做的不是后台有一个定时器在扫队列。如果一个队列一直没有被消费消息虽然过期了但死信转发动作可能不会立刻发生直到有消费者来拉取时才会触发。2.2 队列积压触发的容量型死信给队列设置x-max-length或x-max-length-bytes当队列中的消息数量或字节数达到上限时新消息的进入会逼迫老消息产生死信。默认情况下是从队列头部最早的消息开始丢弃这些被挤掉的消息会进入死信队列。这个机制很适合做“丢弃旧消息、保留新消息”的场景。比如某个实时推送队列如果消费端短暂故障导致消息积压业务上可能宁愿处理最新的一批消息也不愿意回头补很久之前的数据。这时限制队列长度把超容量的老消息转入死信队列归档既保护了队列不会无限增长也为后续排查留下了线索。不过要注意队列满触发的死信和 TTL 过期触发的死信在x-death里的reason是不一样的前者是maxlen后者是expired。别在排查问题的时候把原因搞混。2.3 消费端拒绝且不重回队列这是最常用的方式。消费者处理消息时如果抛出了异常可以调用basic.reject或basic.nack并把requeue参数设置为 falseRabbitMQ 会认为你明确拒绝了这条消息且不把它放回原队列随即触发死信转发。Spring AMQP 中对应的写法是RabbitListener(queues order.business.queue) public void handleOrder(OrderMessage message, Channel channel, Header(AmqpHeaders.DELIVERY_TAG) long tag) throws IOException { try { // 业务处理 } catch (Exception e) { // 不重回原队列转死信 channel.basicNack(tag, false, false); } }为什么我们不直接用requeuetrue原因在 1.2 里已经提到requeue 是立刻重回原队列头部既没有延迟也没有次数控制本质上等于“重启一个坏掉的程序却不做任何等待”。2.4 一个容易忽略的细节死信转发时的消息属性变化消息在被转发到死信队列时并不是原封不动的。几个常见的属性变化值得关注expiration字段会被移除。如果一条消息因为 TTL 过期而死转发到死信队列时它不会再带着原来的过期时间防止它到了死信队列又被同样的 TTL 再次过期。消息会新增x-death头记录死信原因和原队列信息。如果前一次已经成为死信的消息再次变成死信RabbitMQ 会把新的死信信息合并进x-death数组count会累计。这三点在做重试次数判断时非常关键。比如一条消息第一次进死信队列x-death里 count 是 1如果它从死信队列重新投递到业务队列又失败了再次进入死信时count 可能变成 2。把这个字段读出来就能用来决定“还允许重试几次”。3. 基于死信的延迟重试用 TTL 搭出重试阶梯3.1 为什么不能直接 requeue先说清楚一个容易踩坑的认知点RabbitMQ 的 requeue 是“马上重新入队”不是“延迟一段时间再入队”。你可能会想我在捕获到异常之后 sleep 几秒钟再调用 requeue是不是就有延迟效果了理论上能实现但在生产环境里千万别这么做。你在消费者线程里 sleep相当于把整条消费链路阻塞住后面的消息全部排队等着。如果一个消费者同时订阅多个队列其他队列的消息也会被阻塞掉。更不要说 sleep 状态下进程重启、消息重复投递、计数丢失这些连锁问题。正确的思路是让消息按照我们的意愿经过一段时间后再重新回到业务队列。RabbitMQ 原生机制里实现延迟投递最稳妥的方式就是借助“死信 TTL”的组合——消息进入一个设置了 TTL 的队列等它过期自动转入业务队列。3.2 一级重试队列的完整搭建配置假设业务队列叫order.business.queue它的死信交换机是exchange.dead先看完整链路生产者把消息投递给exchange.business路由到order.business.queue。order.business.queue消费失败消费者basicNack且 requeuefalse消息进入exchange.dead。exchange.dead根据路由键把消息投递给order.retry.queue重试队列。order.retry.queue设置了x-message-ttl 5000消息进来 5 秒后过期。该队列的死信交换机重新指向exchange.business过期的消息再次回到order.business.queue进入下一轮消费。关键配置如下// 业务队列 MapString, Object bizArgs new HashMap(); bizArgs.put(x-dead-letter-exchange, exchange.dead); bizArgs.put(x-dead-letter-routing-key, rk.retry); MapString, Object retryArgs new HashMap(); retryArgs.put(x-message-ttl, 5000); retryArgs.put(x-dead-letter-exchange, exchange.business); retryArgs.put(x-dead-letter-routing-key, rk.business);这个设计的巧妙之处在于重试队列本身没有消费者它只是充当一个“延迟等待区”。消息到了之后什么也不干静置 5 秒然后因为 TTL 过期自动回到业务队列。你不需要额外写任何定时任务。注意这里要求exchange.dead必须是 Topic 类型的交换机或者至少支持对应的路由。路由键rk.retry要把消息路由到重试队列rk.business要把消息路由回业务队列。3.3 从固定延时到指数退避的设计固定 5 秒的延迟只适合简单的临时故障。如果下游服务已经宕机十分钟消息每 5 秒就回来一次10 分钟内重试了 120 次对下游和消费者都是折磨。更合理的做法是分级延迟也就是指数退避。实现方式很直接准备多级重试队列每一级 TTL 不同。比如重试层级队列名TTL说明第一级order.retry.1s.queue1秒快速重试处理瞬时抖动第二级order.retry.10s.queue10秒短等待处理小故障第三级order.retry.1m.queue60秒中等等待处理较长故障第四级order.retry.5m.queue300秒长等待预留恢复时间消息第一次失败进入第一级回来后如果还是失败我们需要判断它该进第二级还是直接归档。这个判断可以通过读取x-death里的 count 次数来完成。比如int deathCount getDeathCount(message); String retryQueue selectRetryQueue(deathCount); // 根据次数投递到不同 TTL 的延迟队列每个层级的延迟队列死信交换机都指向业务交换机路由键也相同。但业务队列的死信路由键会根据当前重试次数动态决定保证消息能流向下一级。简单总结一下这套逻辑消费失败不是简单地塞回原队列而是先做一个“伤势评估”决定下一次什么时候回来、还能再试几次。对系统而言这是一种更节制的重试行为。3.4 重试次数的控制x-death 捕获数组与业务计数字段x-death虽然记录了死信次数但在生产环境里依赖它做一些逻辑判断要谨慎。因为 count 是累计的死信次数如果一条消息先因为过期死了一次又因为拒绝死了一次数组里可能有多条记录count 的语义就变得复杂了。更可靠的做法是在业务消息体里增加一个retryCount字段每次消费失败时由消费者自行累加并重新投递到延迟队列{ orderId: A12345, retryCount: 2 }消费逻辑变为解析 retryCount如果小于 3返回延迟队列等待下次重试如果已经等于 3则投递到死信归档队列不再折腾。使用业务字段的好处是它可以随消息走完全程即使在复杂的转发链路上也不会丢失而且判断逻辑是应用自己控制的灵活度高。x-death更适合做审计排查不太适合作为唯一的重试次数依据。4. 归档链路设计从死信队列到历史消息仓库4.1 归档前需要先做的三件事重试次数用尽之后消息不能直接删掉。它在业务上代表一条没有被正确处理的请求可能涉及资金、库存或者用户权益。在进入归档阶段之前有三件事必须想清楚首先确定归档的数据结构。至少需要包含原始消息体 payload、消息的 exchange 和 routing key、首次进入队列的时间、最后一次死信的原因和时间、已重试次数、以及业务ID。这些字段在后续排查时缺一不可。其次规划归档的存储位置。最常见的做法是写入数据库因为查询方便、可对接监控和告警系统。如果消息体很大也可以只把消息体存在对象存储里数据库里保留索引。存储介质是 MySQL、Elasticsearch 还是普通文件取决于你后续要怎么用这些归档数据。最后给归档消息定义生命周期。归档不是永久保留建议定义一个保留策略比如保存 30 天后由定时任务清理。否则时间长了归档库会无限膨胀查询越来越慢最终失去归档的价值。4.2 消费死信队列的归档程序写法死信归档的消费者和普通消费者没有本质区别监听归档队列即可。需要注意的点在于归档处理本身必须保证幂等并且尽量不失败。一个比较稳妥的写法是Component public class DeadLetterArchiver { RabbitListener(queues order.dead.archive.queue) public void archive(Message message, Channel channel, Header(AmqpHeaders.DELIVERY_TAG) long tag) throws IOException { long start System.currentTimeMillis(); try { String body new String(message.getBody(), StandardCharsets.UTF_8); // 根据业务ID去重防止重复归档 boolean exists archiveRepository.existsByOrderId(parseOrderId(body)); if (!exists) { archiveRepository.save(buildArchiveEntity(message)); } channel.basicAck(tag, false); } catch (Exception e) { // 归档失败而且不需要再重试时可以考虑记录后丢弃 log.error(归档失败, tag{}, tag, e); channel.basicAck(tag, false); } } }示例里我用了一个有点“激进”的做法归档失败也直接 ack。原因是归档队列的消息本身已经没有重试价值了如果再次 nack 让它死信循环反而会造成队列堆积。更合理的方式是把它写到一个失败补偿表里后续由另一个任务去重试记录。4.3 归档消息的生命周期管理与查询归档消息进入数据库之后建议给它加一个status字段记录当前状态已归档、人工处理中、已修复。这样当业务方反馈“某个订单状态不对”时运维人员可以直接查归档表找到对应的消息体看清它经历了多少次重试、因为什么原因失败、最终卡在哪里。归档表还需要加一条独立的archived_at时间戳。基于这个字段写一个轻量的清理任务定期删除 30 天前的记录。我见过不少团队在归档阶段花了很多功夫却没有考虑数据生命周期结果半年后归档库比业务库还大非常尴尬。如果你的场景对实时性有要求还可以额外配置一套告警归档队列有消息进来时说明有业务消息已经“救不活”了此时触发通知给值班人员尽快人工介入。这样一来死信归档就不仅仅是一个被动的存储行为而是变成了主动发现问题的信号源。5. 实测中踩过的坑死信循环、消息乱序与幂等5.1 死信又死信循环转发是怎么发生的这是新手最容易踩的坑。假设order.business.queue的死信交换机是exchange.dead而exchange.dead的路由又把消息恰好绑回了order.business.queue——那么一条处理失败的消息会立刻变成死信被转发回原队列再次被消费再次失败再次转发形成一个无限循环。这个循环可能不会像 requeue 那么频繁但它会在后台持续占用网络资源与队列读写而且消息的x-death里的 count 会一直膨胀直到把整个消息头撑到很大最后可能因为消息过大被拒绝路由。排查思路很简单查看业务队列的x-dead-letter-exchange指向哪个交换机再查看该交换机绑定了哪些队列。如果绑定关系里出现了原队列本身就说明循环链路已经形成。解决办法是把死信路由键拆分成两个方向一个指向延迟重试队列一个指向人工归档队列二者都不再回到业务队列循环自然就断了。5.2 延迟重试引发的消息顺序漂移在延迟重试机制下消息的顺序性会成为一个问题。假设同一个用户连续下了两笔订单订单 A 先进入队列但因为下游库存服务暂时异常被转进延迟队列等待 10 秒订单 B 后进入队列下游服务刚好恢复了消费成功。于是整个系统的视角里订单 B 先处理完成订单 A 后处理完成业务上如果依赖顺序就会出现“订单 B 已经支付成功订单 A 还在等待重试”的怪象。这个问题本质上是重试机制与顺序性之间的矛盾。如果业务严格要求同一条业务链上的消息有序一般有两条应对思路一是按业务键比如用户ID、订单ID做分区让同一个业务键的消息始终被同一个消费者处理并且在该消费者内部用状态机判断只有前一步完成才允许处理后一步二是在消息体里带上版本号或业务时间戳消费端发现当前处理的消息版本早于已处理版本时直接标记为过期消息放弃处理。对于大多数偏重最终一致性的业务场景来说第二条路更实用。不要追求所有消息严格有序而是保证同一业务键下最终结果正确即可。5.3 归档消费的幂等与重复投递死信队列本身和普通队列一样也可能出现消息重复投递。比如归档消费者在处理一件事情时发生网络抖动RabbitMQ 没有收到正确 ack会把同一条消息再次投递出来。如果归档程序无脑 insert数据库里就会出现重复记录。幂等方案在 4.2 里已经提过以业务ID作为唯一索引。归档保存前先做一次存在性检查或者直接在表上给业务ID加唯一约束插入时使用“存在则跳过”的写入方式。这一步看似简单但能覆盖很多重复投递的隐蔽场景。另外还要注意归档操作本身不要因为单条消息失败而阻塞队列消费。否则死信队列的消息越积越多最终归档积压管理页面上红点一片大家又开始加班排查。6. 一些值得保留的设计习惯最后分享几个我在多次实践中沉淀下来的设计习惯谈不上标准答案但确实帮我少踩了不少坑。归档队列的消费者可以单独拆一个应用进程跑不要和业务消费者混在一起。归档逻辑虽然不重但它涉及数据库写入如果和在线业务共用线程池有可能在数据库抖动时互相影响。拆分以后业务的稳定性和归档的吞吐量都能独立调优。延迟重试的时间参数不要让每一条消息都写到配置中心频繁改动反而容易出问题。通常的做法是固定几档 TTL按档位选择配置简单也容易排查问题。真正需要动态调整的场景不多不要过早引入复杂度。重试过程中的日志比最终成功或失败的日志更重要。建议每一步都打上业务ID、当前队列、死信原因和重试次数。线上排查问题时往往就是靠这些日志把完整的重试链路还原出来的。最核心的一条死信队列不是用来兜底所有错误的“垃圾桶”它是你可以对失败消息施加控制的机制。在使用它之前先想清楚每条消息的失败到底意味着什么——是临时故障要重试、是数据错误要直接归档、还是需要人工介入。想清楚了再设计队列和路由整个消息系统的健壮性会提升一个档次。