企业官网建设流程全解析

1. 死信队列到底在解决什么问题

1.1 从一个真实踩坑场景说起

消息队列用起来爽，但用久了迟早会遇到一类让人头疼的问题：消息明明发出去了，消费者那边却怎么也处理不了。比如订单系统往队列里丢了一条消息，消费者拿到之后发现数据库连接超时，重试三次还是失败；又比如某条消息的格式跟消费者预期的不一致，每次消费都抛异常，然后这条消息被反复投递，反复失败，形成一个死循环。

我最早接触这个问题的时候，做法很粗暴——在消费逻辑里加 try-catch，捕获异常之后把消息丢掉，然后打一行日志。短期看没问题，但时间一长就出事了：有些消息其实只是临时性故障导致的失败，比如下游服务重启那几分钟，结果被我一刀切地丢掉了，业务数据直接丢失，对账的时候才发现少了几条记录。

后来我才认真去研究 RabbitMQ 提供的**死信队列（Dead Letter Queue，简称 DLQ）**机制。简单说，它做的事情就是：当一条消息在某个队列里无法被正常消费时，不要直接丢弃，而是把它转发到一个专门的队列里存起来，后续可以人工排查、延迟重试或者做补偿处理。

这个机制解决的核心痛点有三个：第一，消息不会因为消费失败而凭空消失，有了兜底；第二，失败消息集中管理，排查问题的时候不用去翻散落各处的日志；第三，可以基于死信做延迟重试，这是很多延迟任务场景的经典实现方式。

适合谁来参考这篇内容？如果你已经用过 SpringBoot 整合 RabbitMQ 做过基本的收发消息，但对消息可靠性、异常兜底这块还没有系统方案，那这篇就是写给你的。如果你还没接触过 RabbitMQ，建议先把基本的交换机、队列、绑定关系搞清楚再来看死信，不然容易一头雾水。

1.2 一条消息什么情况下会变成死信

很多人以为只有“消费失败”才会进死信队列，其实 RabbitMQ 定义的死信触发条件有三类，理解这三类是用好死信队列的前提。

第一类是消息被消费者拒绝（basic.reject 或 basic.nack）并且设置了 requeue=false。注意这里的关键是 requeue 必须为 false，如果设置为 true，消息会被重新放回原队列，不会变成死信。这个设计其实很合理——你告诉 RabbitMQ“这条消息我不要了，也别放回去”，那它就帮你转到死信队列。

第二类是消息过期（TTL 到期）。队列可以设置消息的存活时间，也可以对单条消息设置过期时间。一旦超时，消息还没被消费，就会变成死信。这个特性是延迟队列的基石，后面我会详细讲。

第三类是队列达到最大长度限制。当队列里堆积的消息数量超过设定的 max-length，最早的那些消息会被挤出去，如果配置了死信交换机，这些被挤出去的消息就进入死信队列。

注意：这三类条件是“或”的关系，只要满足任意一个，消息就会走死信路由。而且死信路由的前提是你给原队列绑定了死信交换机（x-dead-letter-exchange），否则消息还是会被直接丢弃。

理解这三类条件之后，你就能明白死信队列不只是“消费失败的垃圾桶”，它其实是一个通用的消息兜底和延迟处理机制。很多看起来跟死信无关的场景，比如订单超时未支付自动取消，底层用的就是 TTL + 死信队列这套组合。

2. SpringBoot 整合死信队列的整体设计思路

2.1 核心组件与流转链路

在动手写代码之前，先把整个链路的组件关系理清楚，不然配置的时候很容易搞混交换机和队列的绑定方向。

整个死信机制涉及的核心组件有四个：业务交换机（Business Exchange）、业务队列（Business Queue）、死信交换机（Dead Letter Exchange）、死信队列（Dead Letter Queue）。流转逻辑是这样的：生产者把消息发到业务交换机，业务交换机根据路由键把消息投递到业务队列，消费者从业务队列取消息消费。当消息在业务队列里满足死信条件时，RabbitMQ 会把它重新投递到死信交换机，死信交换机再根据路由键投递到死信队列，最后由专门处理死信的消费者来消费。

这里有个特别容易踩的坑：死信交换机和死信队列的绑定关系，是在业务队列上声明的，不是在死信队列上声明的。也就是说，你需要在创建业务队列的时候，通过参数x-dead-letter-exchange指定死信交换机，通过x-dead-letter-routing-key指定转发时用的路由键。很多人第一次配的时候，跑去死信队列上加参数，结果怎么都不生效，就是因为搞反了方向。

2.2 为什么选择死信队列而不是自己写重试逻辑

有朋友可能会问：我在消费端自己写个重试计数，失败几次之后存到数据库，不也能实现类似效果吗？为什么非要用死信队列？

这个问题我认真对比过。自己写重试逻辑的问题在于：第一，重试状态需要额外存储，你得维护一个计数表或者用 Redis 记录每条消息重试了几次，增加了系统复杂度；第二，重试的时机不好控制，如果失败后立刻重试，下游服务可能还没恢复，重试大概率还是失败，如果延迟重试，你又得引入定时任务去扫描；第三，消息的原始信息容易丢失，自己处理的时候稍不注意就把消息体弄丢了，排查问题没有依据。

而死信队列是 RabbitMQ 原生支持的机制，不需要额外的存储和定时任务，消息的原始内容、头部信息、死亡原因都完整保留。尤其是配合 TTL 使用的时候，天然就能实现延迟重试——消息进死信队列之后设置一个过期时间，到期后再转发回业务队列重新消费，整个过程不需要写一行定时任务代码。

当然，死信队列也不是银弹。它的延迟精度依赖 TTL，而 RabbitMQ 的 TTL 是队列级别的惰性检查，消息过期后不一定立刻被转发，存在一定的延迟抖动。如果你的业务对延迟精度要求极高（比如精确到毫秒级），那死信队列可能不太合适，需要考虑其他方案。但对于大多数业务场景，秒级到分钟级的延迟完全够用。

2.3 项目依赖与基础配置

先把工程骨架搭起来。我用的是 SpringBoot 2.7.x 版本，对应的 spring-boot-starter-amqp 版本跟着父工程走就行。核心依赖就一个：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-amqp</artifactId> </dependency>

application.yml 里的基础配置如下，这里我把关键参数都列出来并说明作用：

spring: rabbitmq: host: 127.0.0.1 port: 5672 username: guest password: guest virtual-host: / listener: simple: acknowledge-mode: manual prefetch: 1 retry: enabled: false

这里有两个参数需要重点说明。acknowledge-mode: manual表示手动确认，这是使用死信队列时强烈建议的模式。因为只有手动确认，你才能在消费失败时主动调用basicNack并设置 requeue=false，从而触发死信路由。如果用自动确认，消息一旦投递给消费者就立刻被标记为已消费，根本没有机会进入死信队列。

retry.enabled: false是关闭 Spring 自带的重试机制。Spring 的 retry 默认会在消费失败时自动重试，重试次数用完之后才抛出异常。如果你开着它，又想在重试耗尽后走死信，逻辑上也能work，但重试是在内存里同步进行的，会阻塞消费线程，而且重试期间消息状态不明确。我个人的习惯是关掉它，自己在业务代码里控制重试和死信逻辑，更可控。

prefetch: 1表示每次只预取一条消息，避免消息在消费者端堆积。这个值在死信场景下比较重要，因为如果预取太多，一旦消费者出问题，这些预取的消息都会变成死信，排查起来更麻烦。

3. 死信队列的完整配置与代码实现

3.1 交换机与队列的声明

配置类是整个死信机制的核心，所有交换机、队列、绑定关系都在这里声明。我习惯把业务和死信的配置分开写，逻辑更清晰。

@Configuration public class RabbitMQConfig { // 业务交换机 public static final String BUSINESS_EXCHANGE = "business.exchange"; // 业务队列 public static final String BUSINESS_QUEUE = "business.queue"; // 业务路由键 public static final String BUSINESS_ROUTING_KEY = "business.routing.key"; // 死信交换机 public static final String DLX_EXCHANGE = "dlx.exchange"; // 死信队列 public static final String DLX_QUEUE = "dlx.queue"; // 死信路由键 public static final String DLX_ROUTING_KEY = "dlx.routing.key"; @Bean public DirectExchange businessExchange() { return new DirectExchange(BUSINESS_EXCHANGE, true, false); } @Bean public DirectExchange dlxExchange() { return new DirectExchange(DLX_EXCHANGE, true, false); } @Bean public Queue businessQueue() { Map<String, Object> args = new HashMap<>(); // 指定死信交换机 args.put("x-dead-letter-exchange", DLX_EXCHANGE); // 指定死信路由键 args.put("x-dead-letter-routing-key", DLX_ROUTING_KEY); // 设置消息过期时间，单位毫秒 args.put("x-message-ttl", 10000); // 设置队列最大长度 args.put("x-max-length", 1000); return QueueBuilder.durable(BUSINESS_QUEUE).withArguments(args).build(); } @Bean public Queue dlxQueue() { return QueueBuilder.durable(DLX_QUEUE).build(); } @Bean public Binding businessBinding() { return BindingBuilder.bind(businessQueue()) .to(businessExchange()) .with(BUSINESS_ROUTING_KEY); } @Bean public Binding dlxBinding() { return BindingBuilder.bind(dlxQueue()) .to(dlxExchange()) .with(DLX_ROUTING_KEY); } }

这段代码里有几个细节值得展开说。x-message-ttl设置为 10000 毫秒，意味着消息进入业务队列后如果 10 秒内没有被消费，就会变成死信。这个参数是实现延迟队列的关键，你可以根据业务需要调整。x-max-length设置为 1000，表示队列最多堆积 1000 条消息，超出的部分会从队头开始被挤出去变成死信。这两个参数不是必须的，但加上之后死信的触发场景更完整。

提示：x-dead-letter-routing-key这个参数如果不设置，死信转发时会沿用消息原本的路由键。但死信交换机和业务交换机通常是不同的，路由键对不上就会导致死信投递失败。所以强烈建议显式设置这个参数，避免踩坑。

3.2 生产者的消息发送

生产者这边没什么特殊的，就是往业务交换机发消息。但为了后续排查方便，我建议在发送时给消息加上唯一 ID 和时间戳，这样即使消息进了死信队列，也能快速定位是哪条业务数据。

@Service public class MessageProducer { @Autowired private RabbitTemplate rabbitTemplate; public void sendBusinessMessage(String content) { MessageProperties props = new MessageProperties(); props.setMessageId(UUID.randomUUID().toString()); props.setTimestamp(new Date()); props.setContentType("application/json"); Message message = new Message(content.getBytes(StandardCharsets.UTF_8), props); rabbitTemplate.send( RabbitMQConfig.BUSINESS_EXCHANGE, RabbitMQConfig.BUSINESS_ROUTING_KEY, message ); System.out.println("消息已发送，ID: " + props.getMessageId()); } }

这里用rabbitTemplate.send而不是convertAndSend，是为了能手动控制消息属性。convertAndSend虽然方便，但消息 ID、时间戳这些元信息不好设置。在死信场景下，这些元信息恰恰是排查问题的关键，所以多写几行代码是值得的。

3.3 消费者的手动确认与死信触发

消费者是死信机制真正生效的地方。核心逻辑是：消费成功就 ack，消费失败就 nack 并且 requeue=false，这样消息就会进入死信队列。

@Component public class BusinessConsumer { @RabbitListener(queues = RabbitMQConfig.BUSINESS_QUEUE) public void consume(Message message, Channel channel) throws IOException { long deliveryTag = message.getMessageProperties().getDeliveryTag(); String msgId = message.getMessageProperties().getMessageId(); String body = new String(message.getBody(), StandardCharsets.UTF_8); try { // 模拟业务处理 processBusiness(body); // 处理成功，手动确认 channel.basicAck(deliveryTag, false); System.out.println("消费成功，消息ID: " + msgId); } catch (Exception e) { System.err.println("消费失败，消息ID: " + msgId + "，原因: " + e.getMessage()); // 拒绝消息，requeue=false 触发死信路由 channel.basicNack(deliveryTag, false, false); } } private void processBusiness(String body) { // 实际业务逻辑，失败时抛异常 if (body.contains("error")) { throw new RuntimeException("模拟业务处理失败"); } } }

这里最关键的一行是channel.basicNack(deliveryTag, false, false)。三个参数分别是：deliveryTag（消息标识）、multiple（是否批量拒绝）、requeue（是否重新入队）。第三个参数设为 false，消息才会走死信路由；如果设为 true，消息会被重新放回业务队列，然后再次被消费，再次失败，形成死循环。

注意：如果你用的是basicReject，效果是一样的，但basicReject一次只能拒绝一条消息，basicNack可以批量拒绝。在死信场景下我一般用basicNack，因为语义更清晰。

3.4 死信消费者的处理策略

死信队列里的消息怎么处理，取决于你的业务需求。常见的策略有三种：人工介入、延迟重试、记录归档。

人工介入适合那些需要人工判断的消息，比如格式错误、业务规则冲突等。死信消费者只负责把消息落库或者发告警，不自动处理。

延迟重试适合临时性故障，比如下游服务短暂不可用。做法是死信消费者把消息重新发回业务队列，但中间加一个延迟，避免立刻重试又失败。

记录归档适合那些确认无法处理的消息，直接存到数据库或者日志系统，保留证据即可。

下面是一个延迟重试的实现示例，思路是死信消费者收到消息后，不直接处理，而是转发到一个延迟队列，延迟队列到期后再转发回业务队列：

@Component public class DlxConsumer { @Autowired private RabbitTemplate rabbitTemplate; @RabbitListener(queues = RabbitMQConfig.DLX_QUEUE) public void consumeDlx(Message message, Channel channel) throws IOException { long deliveryTag = message.getMessageProperties().getDeliveryTag(); String body = new String(message.getBody(), StandardCharsets.UTF_8); try { // 记录死信日志 System.err.println("收到死信消息: " + body); // 这里可以做落库、告警等操作 // 如果决定重试，重新发送到业务交换机 // rabbitTemplate.send(BUSINESS_EXCHANGE, BUSINESS_ROUTING_KEY, message); channel.basicAck(deliveryTag, false); } catch (Exception e) { channel.basicNack(deliveryTag, false, false); } } }

实际生产中，我会在死信消费者里加一个重试次数的判断。消息头里可以带一个自定义的重试计数，每次进死信就加一，超过阈值就不再重试，直接落库告警。这样既给了临时故障恢复的机会，又避免了无限重试。

4. 延迟队列场景的实战应用

4.1 TTL 加死信实现延迟任务的原理

延迟队列是死信机制最经典的应用场景。所谓延迟任务，就是“消息发送后不立刻消费，而是等一段时间再消费”。比如订单创建后 30 分钟未支付就自动取消，这个“30 分钟后”就是延迟。

RabbitMQ 本身没有直接提供延迟队列的功能，但通过 TTL + 死信队列可以间接实现。原理是这样的：创建一个业务队列，不设置消费者，只设置消息 TTL。生产者把消息发到这个队列，消息在队列里等待，TTL 到期后变成死信，转发到死信交换机，死信交换机再投递到死信队列，死信队列上有消费者，收到消息时距离发送已经过了 TTL 设定的时间，从而实现了延迟。

这个方案的好处是不需要额外的插件，纯靠 RabbitMQ 原生能力就能实现。缺点是延迟精度不够高，因为 RabbitMQ 对 TTL 的检查是惰性的——它不会为每条消息启动一个定时器，而是在消息即将被投递时才检查是否过期。如果队列头部消息的 TTL 很长，后面的消息即使 TTL 很短，也得等头部消息过期后才能被检查到，这就是所谓的“队头阻塞”问题。

4.2 延迟队列的配置与代码

延迟队列的配置跟普通死信队列略有不同，核心是业务队列不设消费者，只作为“等待区”。

@Configuration public class DelayQueueConfig { public static final String DELAY_EXCHANGE = "delay.exchange"; public static final String DELAY_QUEUE = "delay.queue"; public static final String DELAY_ROUTING_KEY = "delay.routing.key"; public static final String DELAY_DLX_EXCHANGE = "delay.dlx.exchange"; public static final String DELAY_DLX_QUEUE = "delay.dlx.queue"; public static final String DELAY_DLX_ROUTING_KEY = "delay.dlx.routing.key"; @Bean public DirectExchange delayExchange() { return new DirectExchange(DELAY_EXCHANGE, true, false); } @Bean public DirectExchange delayDlxExchange() { return new DirectExchange(DELAY_DLX_EXCHANGE, true, false); } @Bean public Queue delayQueue() { Map<String, Object> args = new HashMap<>(); args.put("x-dead-letter-exchange", DELAY_DLX_EXCHANGE); args.put("x-dead-letter-routing-key", DELAY_DLX_ROUTING_KEY); // 延迟 30 分钟，单位毫秒 args.put("x-message-ttl", 30 * 60 * 1000); return QueueBuilder.durable(DELAY_QUEUE).withArguments(args).build(); } @Bean public Queue delayDlxQueue() { return QueueBuilder.durable(DELAY_DLX_QUEUE).build(); } @Bean public Binding delayBinding() { return BindingBuilder.bind(delayQueue()) .to(delayExchange()) .with(DELAY_ROUTING_KEY); } @Bean public Binding delayDlxBinding() { return BindingBuilder.bind(delayDlxQueue()) .to(delayDlxExchange()) .with(DELAY_DLX_ROUTING_KEY); } }

生产者往delay.exchange发消息，消息进入delay.queue后等待 30 分钟，然后变成死信转发到delay.dlx.queue，消费者监听delay.dlx.queue即可。

提示：延迟队列的 TTL 是队列级别的，意味着这个队列里所有消息的延迟时间都一样。如果你需要不同的延迟时间，比如有的 10 分钟、有的 30 分钟，那就得创建多个延迟队列，每个队列设置不同的 TTL。这是这个方案的一个局限。

4.3 队头阻塞问题的规避

前面提到的队头阻塞问题，在实际使用中会造成延迟时间不准。举个例子，你先发了一条 TTL 为 30 分钟的消息，又发了一条 TTL 为 10 分钟的消息。按理说第二条应该 10 分钟后就进死信，但实际上它得等第一条 30 分钟过期之后才能被检查到，结果延迟了 30 分钟。

规避这个问题的办法有几种。第一种是拆分队列，不同延迟时间的消息发到不同的队列，每个队列的 TTL 固定，这样就不会互相阻塞。第二种是使用延迟插件，RabbitMQ 有一个官方延迟插件，支持消息级别的 TTL，不存在队头阻塞，但需要额外安装插件，部署成本高一些。第三种是在消息头里记录目标执行时间，消费者收到消息后判断是否到了执行时间，没到就重新入队，但这又引入了新的复杂度。

我个人的选择是：如果延迟时间种类不多（比如就 3 到 5 种），直接用拆分队列的方案，简单可靠；如果延迟时间很灵活，种类很多，那就考虑延迟插件。不要为了省事用单队列加消息级 TTL，队头阻塞会让你怀疑人生。

5. 常见问题排查与避坑经验

5.1 死信不生效的排查思路

死信队列配好了但消息不进死信，这是最常见的问题。我整理了一个排查清单，按顺序检查基本能定位到原因。

其中最容易忽略的是最后一条。RabbitMQ 的队列一旦创建，属性就固定了。如果你改了代码里的 TTL 或者死信交换机配置，但队列已经存在，新配置不会生效，必须先把旧队列删掉再重新创建。我在这上面浪费过整整一个下午，一直以为代码写错了，最后发现是队列没删。

注意：生产环境删队列要慎重，队列里可能还有未消费的消息。建议在开发阶段就用带版本号的队列名，比如business.queue.v2，避免属性冲突。

5.2 消息重复消费的处理

死信机制本身不保证消息不重复。一条消息可能因为网络抖动、消费者重启等原因被多次投递，尤其是在手动确认模式下，如果 ack 丢失，消息会被重新投递。

处理重复消费的标准做法是幂等设计。具体来说，可以在消费逻辑里用消息 ID 做去重，比如把处理过的消息 ID 存到 Redis，消费前先查一下是否处理过。也可以用业务唯一键做去重，比如订单号，处理前先查数据库是否已有记录。

@Autowired private StringRedisTemplate redisTemplate; private boolean isProcessed(String msgId) { Boolean result = redisTemplate.opsForValue() .setIfAbsent("msg:processed:" + msgId, "1", 24, TimeUnit.HOURS); return Boolean.FALSE.equals(result); }

setIfAbsent是原子操作，返回 false 说明 key 已存在，消息处理过了，直接 ack 跳过即可。这个方案简单有效，但要注意设置合理的过期时间，避免 Redis 无限增长。

5.3 死信消息的监控与告警

死信队列如果没人管，时间长了会堆积成山，等到发现的时候可能已经积压了几十万条消息。所以监控和告警是必须的。

最基本的监控是死信队列的消息数量。可以通过 RabbitMQ 的 HTTP API 定期查询队列深度，超过阈值就告警。SpringBoot 的 Actuator 也提供了 RabbitMQ 的指标端点，可以接入 Prometheus 做监控。

@Scheduled(fixedDelay = 60000) public void checkDlxQueueDepth() { Properties props = rabbitTemplate.execute(channel -> { // 通过 channel 查询队列消息数 return channel.queueDeclarePassive(RabbitMQConfig.DLX_QUEUE).getMessageCount() > 100 ? null : null; }); }

更简单的做法是用RabbitAdmin的getQueueProperties方法获取队列信息。不过说实话，生产环境我更推荐直接用 RabbitMQ 的管理界面或者 API 做监控，代码里写监控逻辑反而增加复杂度。

告警渠道可以是邮件、企业微信、钉钉等。关键是告警要有上下文，不能只报一个数字，要带上队列名、当前深度、增长趋势，这样排查的时候才有方向。

5.4 死信消息的批量重投

有时候死信队列里积压了一批消息，修复了下游问题之后需要批量重投。手动一条条重发不现实，得写个工具。

思路很简单：从死信队列消费消息，重新发送到业务交换机，然后 ack 掉死信消息。但要注意控制速率，别一下子全放出去把下游打垮。

@RabbitListener(queues = RabbitMQConfig.DLX_QUEUE) public void reprocessDlx(Message message, Channel channel) throws IOException { long deliveryTag = message.getMessageProperties().getDeliveryTag(); try { // 重新发送到业务交换机 rabbitTemplate.send( RabbitMQConfig.BUSINESS_EXCHANGE, RabbitMQConfig.BUSINESS_ROUTING_KEY, message ); // 限流，避免下游压力过大 Thread.sleep(100); channel.basicAck(deliveryTag, false); } catch (Exception e) { channel.basicNack(deliveryTag, false, false); } }

这个工具建议做成开关控制的，需要的时候手动触发，不要常驻运行。因为死信消息重投之后如果还是失败，又会回到死信队列，形成循环。所以重投之前一定要确认下游问题已经修复。

6. 生产环境的配置建议与经验总结

6.1 参数配置的取舍

生产环境的参数配置跟开发环境差别很大，我列几个关键参数的建议值。

x-message-ttl不要设得太短。开发环境设 10 秒没问题，生产环境如果设太短，正常消费还没完成消息就过期了，会造成大量误判死信。建议根据业务处理耗时来定，一般是平均耗时的 10 倍以上。

x-max-length要结合队列的消费能力来定。如果消费者处理速度稳定，队列深度一般不会太大，设个几千就够了。如果设得太大，消息堆积到触发上限时，会一次性产生大量死信，给死信消费者造成压力。

prefetch的值在死信场景下建议设小一点，1 到 10 之间。设大了会导致消息在消费者端堆积，一旦消费者出问题，这些消息全部变成死信，排查起来很麻烦。

死信队列的消费者并发数要控制。死信消息通常需要人工关注，处理速度不宜太快，否则告警信息会刷屏。我一般把死信消费者的并发设为 1，慢慢处理，确保每条死信都被认真对待。

6.2 死信消息的存储策略

死信消息不能只放在 RabbitMQ 里，因为队列容量有限，而且 RabbitMQ 重启或者磁盘满了可能导致消息丢失。我的做法是死信消费者收到消息后立刻落库，存到一张专门的死信表里，字段包括消息 ID、原始内容、死亡原因、死亡时间、重试次数、处理状态等。

落库之后，后续的排查、重投、归档都基于数据库操作，不再依赖 RabbitMQ 的队列。这样即使死信队列被清空或者 RabbitMQ 出问题，消息也不会丢。数据库表可以定期归档，把处理完成的老数据转移到历史表，保持主表轻量。

6.3 我踩过的几个坑

第一个坑是死信交换机和业务交换机用了同一个。当时图省事，想着反正都是交换机，共用一个得了。结果死信消息转发的时候，路由键跟业务路由键一样，又回到了业务队列，形成死循环。后来老老实实分开建了两个交换机，问题解决。

第二个坑是在死信消费者里抛异常。死信消费者处理失败时，如果直接抛异常，消息会被 nack 然后重新入队，又变成死信，无限循环。正确的做法是死信消费者里做好兜底，处理失败就落库记录，然后 ack 掉，不要让消息再回到队列。

第三个坑是忘了给死信队列设消费者。配置都对了，消息也进死信队列了，但没人消费，堆在那里越来越多。后来加了个定时任务监控队列深度，超过阈值就告警，才及时发现这个问题。

第四个坑是TTL 设置后修改不生效。前面提过，队列属性一旦创建就固定了，改代码没用，必须删队列重建。这个坑我踩了两次，第二次是因为忘了第一次的教训。现在我的习惯是，只要改了队列参数，第一件事就是去管理界面确认队列是否被删除重建。

6.4 后续可以扩展的方向

死信队列玩熟之后，可以往几个方向扩展。一个是结合延迟插件做更灵活的延迟任务，摆脱 TTL 队列级别的限制。另一个是做死信消息的可视化管理界面，把死信表的数据展示出来，支持筛选、重投、标记处理等操作，减少人工排查成本。还有一个方向是做死信消息的自动分类，根据死亡原因自动打标签，比如“网络超时”“格式错误”“业务规则冲突”，然后针对不同类别走不同的处理流程。

这些扩展不是必须的，但如果你负责的系统对消息可靠性要求很高，死信队列的管理能力就是刚需。我个人的体会是，死信队列本身不难，难的是配套的监控、告警、存储、重投这一整套流程。把这套流程跑通之后，消息中间件的可靠性才算真正有了保障。