企业官网建设流程全解析

做分布式事务做到第三篇，前面聊了生产者如何可靠投递、消息如何通过事务消息保证最终一致性，今天终于轮到消费端。很多时候我们把消息发出去就以为万事大吉，实际上真正容易翻车的恰恰是消费这一环。消费端一旦丢消息、重复处理、失败后没有兜底，前面投递做得再稳也是白搭。所以这篇我重点拆解RabbitMQ可靠消费的完整套路：手动确认、重试与死信、幂等设计，再配一个积分发放的完整案例，把踩过的坑一并讲清楚。

1. 可靠消费的核心问题与整体设计思路

1.1 为什么消费端是分布式事务的最后一道关

分布式事务的最终目标是数据一致，但消息从生产者发出到消费者真正改库，中间隔着网络、队列、应用进程、数据库事务。任何一个环节失败，都可能造成数据不一致。前面两篇解决的是“消息一定能从生产者到达Broker”的问题，但Broker把消息推给消费者之后，消费者本地事务失败怎么办？消息被重复投递怎么办？消费者处理到一半宕机了，消息算成功还是失败？

这些问题的答案全部落在消费端。可靠消费本质上要回答三件事：消息有没有被正确处理、处理失败后有没有重试机会、重复投递时业务数据会不会被搞乱。这三个问题不解决，哪怕Broker再怎么高可用，分布式事务依然会漏洞百出。

从实际项目看，不少团队在生产环境出过类似事故：消费者里直接调用业务方法，没有手动确认，进程一重启消息丢了；或者失败后直接throw new RuntimeException，没有重试机制，消息进入死信队列后无人处理；再或者下游接口超时，重试导致同一笔订单被处理了两遍。这些问题的根源，都是没有把消费端当成一个独立的可靠性系统来设计。

1.2 可靠消费的目标与关键点拆解

可靠消费的最终目标可以概括为一句话：每条消息至少被正确处理一次，且重复处理不会产生业务影响。这里有两个关键短语，一个是“至少一次”，一个是“不产生业务影响”。前者靠消息确认机制来保证，后者靠幂等设计来兜底。

拆解下来，可靠消费有三个核心环节：

• 消息确认：消费者处理完成后必须显式通知Broker，告知消息可以删除；处理失败则通知Broker重新投递或转移。
• 重试机制：失败的消息不能直接丢弃，需要有策略地重试，重试仍失败则进入死信或人工处理流程。
• 幂等控制：无论消息被投递多少次，业务结果只能生效一次，这需要业务侧配合，用唯一键或状态机来拦截重复请求。

这三个环节缺一不可。确认机制解决“消息丢没丢”，重试机制解决“失败怎么办”，幂等机制解决“重复会不会错”。把它们串起来，才是一条完整的可靠消费链路。

1.3 技术选型：手动ACK + 重试队列 + 幂等表

我个人的做法是，消费端坚持三件套：

• 关闭自动确认（autoAck=false），使用手动ACK。
• 消费失败后，不无限重试，而是将消息转入延迟队列/死信队列，通过TTL+死信交换机实现延迟重试。
• 业务数据库中建立幂等表，用业务唯一键约束保证重复消息不会重复生效。

这套组合的好处是：不依赖任何外部中间件，纯RabbitMQ原生能力即可实现；每个环节责任单一，排查问题非常直观；而且能覆盖绝大多数业务场景。当然如果你用的是Spring Cloud Stream或RocketMQ，可能有事务消息等更高级的玩法，但RabbitMQ生态下，这三件套就是最稳的落地姿势。

2. 消息确认机制：从自动ACK到手动ACK的关键转变

2.1 自动确认的隐患

RabbitMQ消费者默认是自动确认模式。所谓自动确认，就是Broker把消息推给消费者后，不管消费者的业务逻辑是否执行成功，立即把这条消息标记为已消费并删除。这个模式下，消费者进程在收到消息和真正处理消息之间只要有任何异常——比如网络闪断、OOM、代码Bug——消息就永远丢了。

我们线上曾经出过一个问题：消费者监听一个支付回调队列，代码里先用Thread.sleep模拟处理耗时，结果某次发布变更后代码抛了空指针，但消息已经被自动ACK掉了。支付成功了，积分没发放，用户找过来才知道出了问题。这就是自动确认最大的坑：它只保证“消息被投递”，不保证“消息被成功处理”。

自动确认唯一的优点是吞吐高，少一次网络往返。但分布式事务场景里，可靠性优先级远高于吞吐。所以但凡涉及资金、积分、订单状态变更这类核心数据，必须切手动ACK。

2.2 手动ACK的正确姿势：basicAck、basicNack、basicReject

切到手动确认后，消费者代码里需要显式调用三种方法之一：

• basicAck(deliveryTag, multiple)：确认消息处理成功，Broker删除该消息。
• basicNack(deliveryTag, multiple, requeue)：否定消息，可以选择是否重新入队。推荐将requeue设为false，避免无限循环。
• basicReject(deliveryTag, requeue)：拒绝单条消息，等价于basicNack的简化版，但没有multiple参数。

这里要特别注意deliveryTag。它是每个消费者Channel内自增的编号，从1开始。multiple参数表示是否批量确认，如果设为true，会确认所有小于等于该deliveryTag的消息。日常开发建议multiple设为false，逐条确认，逻辑更清晰。

还有一个容易忽略的细节：手动ACK必须与业务事务在同一个边界内。要么先处理业务，成功后再ACK；要么先ACK再处理业务——但绝不推荐后者，因为ACK后进程崩溃消息就丢了。正确的顺序是：业务逻辑执行成功 → 提交本地事务 → 发送ACK。如果业务逻辑失败，走异常分支，调用basicNack(requeue=false)把消息转死信。

2.3 配置与消费者代码骨架

如果你用Spring Boot + Spring AMQP，配置非常简洁。首先在配置里关掉自动确认：

spring.rabbitmq.listener.simple.acknowledge-mode=manual spring.rabbitmq.listener.simple.prefetch=10

prefetch是每次从Broker预取的消息数量。这里我设置为10，表示消费者本地缓存10条消息，避免一次拉取太多导致内存压力。如果业务处理慢，可以把prefetch调小到3~5，让消息更均匀地分布在多个消费者上。

消费者代码骨架如下：

@RabbitListener(queues = "order.pay.success.queue") public void onMessage(Message message, Channel channel) throws Exception { long deliveryTag = message.getMessageProperties().getDeliveryTag(); try { // 1. 幂等判断 if (idempotentService.check(message)) { // 2. 核心业务处理 businessService.handle(message); // 3. 业务成功后确认 channel.basicAck(deliveryTag, false); return; } // 幂等已处理过，直接确认 channel.basicAck(deliveryTag, false); } catch (Exception e) { log.error("消费失败，消息进入死信", e); // 不重新入队，让消息进入死信交换机 channel.basicNack(deliveryTag, false, false); } }

这段代码看起来简单，但有几个关键点必须说清楚。幂等判断要放在最前面，确认check方法本身要支持并发。basicNack的requeue一定要传false，否则失败消息会不断重回队头，卡死消费者。另外，如果重试策略是“本地重试N次后再Nack”，那catch块里还要加重试逻辑，后面单独讲。

2.4 实际踩坑：消息丢失与重复的边界情况

手动确认模式同样有边界问题，最常见的两个：

先ACK后处理导致消息丢失。有人为了减少消息积压，先basicAck再执行业务。如果业务执行到一半宕机，消息就丢了，而且没有任何补偿机会。正确做法始终是先处理后确认，哪怕ACK延迟一点，也不能本末倒置。

网络抖动导致重复投递。消费者执行完业务，在发送ACK的过程中网络断开了，Broker没有收到ACK，会认为消息未消费，重新投递给其他消费者。这时候同一笔业务被执行两次。所以我说，只要用消息队列，重复消费就无法完全避免，必须用幂等来兜底。

还有一点：手动确认模式下，如果消费者抛出异常而没有调用basicNack或basicAck，该消息会一直处于Unacked状态，直到消费者连接断开才会重新入队。所以@RabbitListener方法内部不要轻易吞异常，要么处理掉，要么明确Nack。

3. 消费失败后的重试策略与死信处理

3.1 消费重试的三种方案对比

消息处理失败后，不能直接丢弃，也不能无限重试。业界常见三种方案：

• 本地重试：在消费者代码里用for循环或@Retryable注解重试几次。优点是简单，缺点是一旦进程重启，重试状态丢失；而且重试期间消息一直Unacked，容易阻塞其他消息。
• 延迟队列重试：把失败消息发送到一个带TTL的延迟队列，过期后自动转入原消费队列重新消费。优点是不会阻塞主队列，且重试间隔可控。
• 死信队列重试：利用RabbitMQ死信交换机，把重试N次仍失败的消息转入死信队列，由单独程序扫描处理或人工介入。

我推荐的组合是：消费者本地重试2~3次，处理瞬时抖动；仍然失败就Nack进死信；同时设置死信队列的消费者进行定期扫描重投或人工补偿。这样既不会无限重试拖垮系统，也不会让失败消息石沉大海。

3.2 基于死信队列的重试机制实现

RabbitMQ有一个非常实用的特性：消息被basicNack(requeue=false)时，如果声明队列时绑定了x-dead-letter-exchange，消息会被路由到死信交换机。利用这一点，我们可以构建一个“失败消息 -> 延迟 -> 重新消费”的闭环。

具体做法是定义三个队列：

1. 主消费队列biz.queue，绑定死信交换机biz.dlx，并设置x-dead-letter-routing-key=retry.
2. 延迟队列biz.retry.queue，设置了x-message-ttl=30000（30秒），并绑定死信交换机biz.dlx，死信路由键为main.
3. 主队列的消费者失败后basicNack(requeue=false)，消息进入死信交换机，被路由到延迟队列。延迟队列里的消息等待30秒后过期，由于它自己也绑定了死信交换机，过期后再次进入死信交换机，最终路由回biz.queue，实现延迟重试。

用Spring AMQP声明这些队列时，代码大概是这样的：

@Bean public Queue mainQueue() { return QueueBuilder.durable("biz.queue") .withArgument("x-dead-letter-exchange", "biz.dlx") .withArgument("x-dead-letter-routing-key", "retry") .build(); } @Bean public Queue retryQueue() { return QueueBuilder.durable("biz.retry.queue") .withArgument("x-message-ttl", 30000) .withArgument("x-dead-letter-exchange", "biz.dlx") .withArgument("x-dead-letter-routing-key", "main") .build(); } @Bean public DirectExchange deadLetterExchange() { return new DirectExchange("biz.dlx"); } @Bean public Binding mainBinding() { return BindingBuilder.bind(mainQueue()).to(deadLetterExchange()).with("main"); } @Bean public Binding retryBinding() { return BindingBuilder.bind(retryQueue()).to(deadLetterExchange()).with("retry"); }

这样消息每次消费失败，都会在延迟队列里待30秒再回来，形成间隔重试。如果不想无限循环，可以在消息属性里增加重试次数标记，或者使用不同的TTL实现退避。

3.3 重试参数配置：次数、间隔与退避策略

重试参数不是拍脑袋定的，要结合业务容忍延迟和下游系统能力。我建议：

• 首次失败：本地重试2次，间隔1秒和3秒，解决网络抖动、数据库连接池暂时不可用等问题。
• 本地重试仍失败：进入延迟队列，TTL设置30秒，让消息过30秒再重试。
• 延迟重试次数限制：给每条消息带上重试次数，比如用messageProperties.getHeaders()存一个retryCount，消费时+1，超过5次则转入人工死信队列，不让它无限循环。

为什么要限制次数？因为如果下游接口永久故障，比如业务逻辑有Bug，无限重试只会反复打日志、占用线程资源，而且消息堆积在延迟队列里还会影响其他正常消息。更合理的方式是设定上限后转人工。

退避策略上，可以 简单 使用固定TTL，比如每次30秒。如果要更精细，可以用多个延迟队列，TTL分别设为30秒、60秒、120秒，根据retryCount路由到不同延迟队列。实现上稍微复杂，但能避免数据积压。

3.4 重试告警与人工补偿

重试机制不是终点，还要有监控和人工兜底。我习惯在所有消费失败消息进入最终死信队列（人工处理队列）时，发送一条监控告警。比如，监听biz.dead.manual.queue的消费者收到消息后，通知运维和开发人员，同时在管理后台生成一条待处理记录。

人工补偿流程要有明确的台账：消息ID、业务唯一键、失败原因、重试次数、进入时间。建议把异常堆栈存储到独立的日志表或文件，方便排查。实际操作中，我发现很多团队只做了重试，却忽略了人工补偿这一环，结果死信队列越积越多，数据不一致问题一拖再拖。可靠消费的“可靠”二字，一定包含最终有人能兜底。

4. 幂等性设计：分布式事务的最终一致性基石

4.1 为什么必须做幂等：消息重复的三类来源

即使你用了手动确认，消息依然可能重复投递。归纳起来有三类来源：

1. 生产者重试：生产端发送消息时，网络超时导致消息其实已到Broker，但生产者没收到确认，重试发送造成重复消息。
2. 消费者重复投递：消费者处理成功后ACK丢失，Broker重新投递。
3. 集群故障转移：某个Broker节点宕机，消息可能被重新路由或恢复，消费者可能会收到重复消息。

所以不要把幂等当成可选项，而是消费端的第一道防线。在分布式事务场景下，消息重复率可能很低，但一旦发生，业务数据被污染，影响往往是灾难性的。比如用户购买订单自动发券，如果重复发放，优惠券系统直接亏损。

4.2 基于业务唯一键的幂等表方案

目前最通用、最稳的方案是“业务唯一键 + 唯一索引”幂等表。具体做法：

在消费者处理消息前，先往一个幂等表中插入一条记录，记录的主键或唯一键由业务ID和事件类型组合而成。比如订单支付成功事件，可以用order_id + "_PAY_SUCCESS"作为唯一键。如果插入成功，说明这条消息从未处理过，继续执行后续业务；如果插入时唯一索引冲突，说明之前已经处理过，直接ACK跳过。

表结构可以这样设计：

CREATE TABLE `msg_idempotent` ( `id` BIGINT AUTO_INCREMENT PRIMARY KEY, `biz_key` VARCHAR(128) NOT NULL COMMENT '业务唯一键，如订单ID_事件类型', `msg_id` VARCHAR(64) NOT NULL COMMENT '消息ID', `handler` VARCHAR(64) NOT NULL COMMENT '处理方标识', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY `uk_biz_key` (`biz_key`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里的关键是uk_biz_key唯一索引。利用数据库的原子性，天然支持并发安全。插入和业务处理最好在同一事务里，保证“幂等记录”和“业务变更”要么同时成功，要么同时失败。如果业务处理失败，整个事务回滚，幂等记录也被回滚，下次重试可以重新插入并处理。如果业务成功但事务提交前消息重复投递，由于另一个线程插入相同biz_key，会触发唯一索引错误，从而跳过重复处理。

4.3 幂等判断的时序与并发问题

使用幂等表要注意两个关键点：插入与业务同事务，以及并发下唯一索引的兜底。

第一种正确姿势：开启数据库事务 → 尝试插入幂等表 → 如果插入成功，执行业务更新 → 提交事务 → ACK。如果插入时发生DuplicateKey异常，说明已处理过，直接ACK。

第二种正确姿势：先查幂等表判断是否存在，但这种“先查后插”的方式在并发下有窗口期。两个线程同时查到不存在，同时执行业务，仍然产生重复。所以不要依赖查询来判断，一定要用插入的唯一索引来判断。查询只能作为无脑前置过滤，最终判断必须交给数据库约束。

还有一个细节：幂等表不要和业务表放得太近，避免业务表锁竞争。但插入操作又在事务里，所以实际上会有短暂的锁。我通常将幂等表独立出来，放在单独的数据库中，或者至少单独建表，降低耦合。

4.4 其他幂等方案对比：数据库约束、Redis SETNX、状态机

除了幂等表，常见方案还有三种，可以按场景选择：

• 数据库唯一约束：如果业务表本身有唯一键，比如订单号唯一，那么直接用这个唯一键做幂等。适用于“一条消息对应一条业务记录”的场景，实现最简单。
• Redis SETNX：在消费前执行SETNX biz_key timestamp，返回1则处理，返回0则重复。优点是性能高，但Redis不是关系型数据库，key可能过期，需要谨慎设置TTL，且Redis故障时会影响消费判断。适合对性能要求极高、允许短时间重复检测失效的业务。
• 状态机：业务状态从“待处理”变为“处理中”，再由“处理中”变为“已完成”。消费者处理前先检查状态，只有“待处理”才允许更新。这个方案需要业务表有状态字段，适合订单、任务类场景，能有效防止重复，但要求业务表结构和流程设计支持状态流转。

我的经验是：核心资金级业务，一定要用数据库幂等表或唯一约束；非核心、对一致性要求稍低的，可以结合Redis做第一道快速过滤，数据库做最终兜底。不要只用Redis做唯一判断，Redis挂了会直接放行所有重复请求，风险很大。

5. 完整案例：订单支付成功后的积分发放可靠消费

5.1 业务场景与消息链路

假设一个电商系统：用户下单并支付成功后，订单服务发送一条pay.success消息，积分服务消费该消息后给用户增加积分。这个场景是典型的分布式事务。订单支付和积分发放不在同一个数据库事务里，必须通过消息最终一致。

消息链路如下：

• 订单服务在支付成功本地事务中，写一条order_pay_event事件表，同时发送消息到MQ。
• 积分服务监听order.pay.success.queue，消费消息后先幂等判断，再增加用户积分。

这里“幂等”尤其重要，因为支付成功消息如果被重复消费，可能给用户重复加积分。所以必须用到前面的幂等表方案。

5.2 消费者核心代码实现

积分服务消费者完整代码逻辑如下（基于Spring Boot + MyBatis-Plus为例，略去部分模板代码）：

@Component public class PointsConsumer { @Autowired private IdempotentService idempotentService; @Autowired private PointsService pointsService; @RabbitListener(queues = "order.pay.success.queue") public void handlePaySuccess(Message message, Channel channel) throws Exception { long deliveryTag = message.getMessageProperties().getDeliveryTag(); String bizKey = null; try { String body = new String(message.getBody(), StandardCharsets.UTF_8); JSONObject json = JSON.parseObject(body); String orderId = json.getString("orderId"); Long userId = json.getLong("userId"); Integer points = json.getInteger("points"); bizKey = orderId + "_PAY_SUCCESS"; // 1. 幂等检查：尝试插入幂等表，冲突则说明已处理 boolean firstTime = idempotentService.tryInsert(bizKey, message.getMessageProperties().getMessageId()); if (!firstTime) { // 已经处理过，直接确认 channel.basicAck(deliveryTag, false); return; } // 2. 核心业务：给用户增加积分 pointsService.addPoints(userId, points); // 3. 提交事务后确认 idempotentService.confirmSuccess(bizKey); // 如果tryInsert里的事务未提交，这里确认 channel.basicAck(deliveryTag, false); } catch (DuplicateKeyException e) { // 并发下唯一索引冲突，说明其他线程已在处理，直接确认 log.warn("重复消费，直接确认: {}", bizKey); channel.basicAck(deliveryTag, false); } catch (Exception e) { log.error("消费异常，转入死信: {}", bizKey, e); // 请求重新入队，进入延迟队列 channel.basicNack(deliveryTag, false, false); } } }

你会发现代码里幂等判断放在最前面，但具体实现tryInsert需要和业务操作在同一个事务内。这里我给出的tryInsert返回false的情况，包含了两种：一种是之前已经成功处理过，一种是另一个线程正在处理中。两种都应该直接ACK吗？如果另一个线程正在处理但还没提交，我们ACK了会不会导致另一个线程失败后无人重试？

这里要仔细说。如果并发AB两个线程同时拿到同一订单消息，A先插入幂等成功，B插入时唯一冲突。B应该怎么处理？两种选择：A方案，B直接ACK，信任A最终成功；B方案，B不ACK，而是抛出异常让消息重新入队，等下次再查。通常我们选A，因为B和A处理的是同一笔业务，只要A成功了，B没有存在意义。但B直接ACK有一个前提：必须确认A已经“尽力而为”。更稳妥的做法是，B捕获冲突后，查询幂等表的状态。如果状态是“处理成功”，则ACK；如果是“处理中”，则延迟一下重新入队（例如Nack requeue=true），避免过早ACK。不过大多数业务场景，直接ACK加上人工补偿也够用。我在实际代码中会优先选择查询状态，减少极端情况下的事务风险。

为了让事务边界清晰，tryInsert服务可以这样写：

@Transactional public boolean tryInsert(String bizKey, String msgId) { // 尝试插入 try { idempotentMapper.insert(new MsgIdempotent(bizKey, msgId, "POINTS_CONSUMER")); return true; } catch (DuplicateKeyException e) { return false; } }

注意，tryInsert的@Transactional里没有业务操作，业务操作是pointsService.addPoints，两者要能在同一个事务里提交。所以实际的写法应该是把幂等插入和积分更新放在同一个方法/同一个事务中。你可以这样设计：

@Transactional public void handleWithTransaction(String bizKey, String msgId, Long userId, Integer points) { boolean first = tryInsert(bizKey, msgId); if (!first) { throw new DuplicateKeyException("重复"); } pointsService.addPoints(userId, points); }

然后消费者调用这个事务方法。如果tryInsert抛重复异常，事务回滚，但幂等记录不会插入；此时消费者捕获DuplicateKeyException，直接ACK。如果事务成功，幂等记录和积分发放一起提交。这样做最严谨。

5.3 队列与交换机配置

完整配置需要三部分组成：正常队列、延迟队列、死信交换机，以及对应的Binding。

@Configuration public class RabbitConfig { public static final String MAIN_QUEUE = "order.pay.success.queue"; public static final String RETRY_QUEUE = "order.pay.success.retry.queue"; public static final String DEAD_LETTER_QUEUE = "order.pay.success.manual.queue"; public static final String DLX = "order.pay.success.dlx"; public static final String RETRY_ROUTING_KEY = "retry"; public static final String MAIN_ROUTING_KEY = "main"; @Bean public Queue mainQueue() { return QueueBuilder.durable(MAIN_QUEUE) .withArgument("x-dead-letter-exchange", DLX) .withArgument("x-dead-letter-routing-key", RETRY_ROUTING_KEY) .build(); } @Bean public Queue retryQueue() { return QueueBuilder.durable(RETRY_QUEUE) .withArgument("x-message-ttl", 30000) .withArgument("x-dead-letter-exchange", DLX) .withArgument("x-dead-letter-routing-key", MAIN_ROUTING_KEY) .build(); } @Bean public Queue manualQueue() { return QueueBuilder.durable(DEAD_LETTER_QUEUE).build(); } @Bean public DirectExchange dlxExchange() { return new DirectExchange(DLX); } @Bean public Binding mainRetryBinding() { return BindingBuilder.bind(retryQueue()).to(dlxExchange()).with(RETRY_ROUTING_KEY); } @Bean public Binding retryMainBinding() { return BindingBuilder.bind(mainQueue()).to(dlxExchange()).with(MAIN_ROUTING_KEY); } @Bean public Binding manualBinding() { return BindingBuilder.bind(manualQueue()).to(dlxExchange()).with("manual"); } }

这套声明方式，靠死信交换机把主队列和延迟队列串起来。消息在主队列消费失败，Nack(requeue=false)，进入死信交换机，路由到延迟队列，等待30秒后过期，再通过延迟队列自己的死信路由回到主队列。这样完成一轮重试。如果重试多次后仍失败，我们可以在业务代码中根据头信息决定是否手动将消息投递到manual队列。

5.4 测试验证与常见效果

本地测试时，我习惯先模拟两个场景：

1. 积分服务首次启动正常消费，观察到消息被ACK，数据库多了积分流水和幂等记录。
2. 消费时直接抛异常，观察消息在管理后台的流向：主队列消息减少，延迟队列先增加消息，30秒后延迟队列消息消失，主队列再次收到同一消息。

用管理后台可以看到消息在队列之间的流转。如果你加一个测试消费者监听manual队列，可以快速验证死信路径是否走通。

实际测试中，我发现一个容易忽略的点：延迟队列里的消息如果不触发任何消费者，它不会自动过期。因为RabbitMQ的TTL是基于“消息在队列中的存活时间”，只有消息在队列头部的时候才会被检查过期并进入死信交换。如果延迟队列积压了很多消息，排在后面的消息即使TTL到了，也要等前面的消息被消费或过期，才会轮到它。所以不要指望延迟队列能精确控制每条消息的重试时间，如果重试消息量大，需要考虑用不同TTL的队列做分级。

6. 常见问题与排查技巧实录

6.1 典型问题速查表

6.2 排查思路：从队列监控到日志定位

遇到消费问题，我习惯按这个顺序排查：

1. 看RabbitMQ管理后台的Queues页面，关注Ready、Unacked、Total三个数字。Unacked突然增大，说明消费者卡住了；Ready长期不为0，说明消费速度跟不上。
2. 看消费者日志，重点搜basicNack、basicAck和异常堆栈。我会在Ack/Nack前后都打一行日志，带消息ID和业务唯一键，这样能精确追踪每条消息的命运。
3. 看幂等表，查询对应biz_key是否存在，判断是“重复消费”还是“首次消费失败”。如果幂等表有记录但业务表没有，说明事务没控制好。
4. 看延迟队列和死信队列的流量，结合时间点判断是否因为代码Bug导致大量消息进入重试循环。

还有一个非常实用的技巧：给每个消费者设置一个唯一的消费组标识，同时在消息header里记录x-original-queue、x-death信息。RabbitMQ死信消息会自动带上x-death头，里面记录了被死信的原因（如rejected、expired）和次数。排查死信问题时，直接查看消息体的headers，能快速定位是被谁拒收的。

6.3 独家避坑：Unacked消息导致队列卡死

有一次线上事故，某个消费者抛异常没有Nack，也没有Ack，所有消息堆积成Unacked。因为Spring AMQP默认行为是发生异常后消息会被自动恢复吗？并不是。@RabbitListener如果方法抛出异常，会默认调用basicNack并带入requeue=true，导致消息重新入队，单条消息反复失败，形成死循环。如果不设置重试上限，这个循环会一直跑下去。

后来我改了配置：在SimpleRabbitListenerContainerFactory里设置defaultRequeueRejected(false)，让失败消息直接进死信，而不是无限requeue。配置方法：

@Bean public SimpleRabbitListenerContainerFactory rabbitListenerContainerFactory( ConnectionFactory connectionFactory) { SimpleRabbitListenerContainerFactory factory = new SimpleRabbitListenerContainerFactory(); factory.setConnectionFactory(connectionFactory); factory.setAcknowledgeMode(AcknowledgeMode.MANUAL); factory.setDefaultRequeueRejected(false); factory.setPrefetchCount(10); return factory; }

这样Spring的异常兜底逻辑会Nack且requeue=false，不会再无限循环。但要注意，如果我们在catch里已经手动Nack，就不会走到兜底逻辑。

6.4 关于重试与死信的几个原则

基于这些年的经验，我总结几条原则，供你参考：

• 重试不是越多越好。通常本地重试2~3次，延迟重试最多5次，超过就转人工。
• 消费失败与事务回滚必须一致。手动ACK的时机是业务事务提交后，而不是业务代码执行完。
• 幂等表要和业务同库同步。如果跨库插入幂等记录，事务就不是原子的，容易产生“幂等记录成功但业务失败”的脏状态。
• 不要让普通消息和重试消息混在同一个队列，否则TTL消息积压会影响正常消费。
• 从设计上就考虑延迟重试的时间成本，比如30秒重试意味着用户体验上最多延迟30秒，需要评估业务可接受程度。

这些原则看起来简单，但真正执行到位，需要团队形成共识，而不是靠某个开发同学的自觉。

结尾的话

写到这，RabbitMQ可靠消费的完整链路基本讲透了。我个人在实际操作中的体会是，可靠消费真正难的不是某个单一技术点，而是把确认、重试、幂等、死信、告警这些环节串成一个闭环，并且每个环节都要有日志、有监控、有兜底。很多项目出事，往往不是败在方案不够先进，而是败在某个环节“想当然不会出错”。比如默认开了自动确认、失败了没有转死信、重复消费不幂等——这些看似不起眼的选择，最终都可能在数据一致性的考卷上扣分。

最后再分享一个小技巧：上线前一定要做一次“故障演练”。可以手动往队列里批量塞入重复消息、制造消费者抛异常、把消费者进程kill掉，然后观察消息流转和最终数据是否一致。我每次负责这类项目，都会写几个脚本来模拟这些场景。如果演练之后幂等表无脏数据、死信队列能正常告警、人工补偿能及时处理，那么这个消费端才算是真正“可靠”了。这套方法，也推荐你同样试试。