优先扩容消费者实例并检查消费逻辑耗时，同时调整预取计数（prefetch_count）避免单点阻塞，必要时启用死信队列隔离异常消息。

命令速用版

# 查看队列消息积压数
rabbitmqctl list_queues name messages_ready messages_unacknowledged
# 查看消费者连接状态
rabbitmqctl list_consumers queue consumer_tag arguments
# 查看队列详细信息（含策略）
rabbitmqctl list_queues name policy

为什么会这样

消息积压通常是因为消费速度低于生产速度。导致消费超时的常见原因包括消费者处理单条消息耗时过长、消费者进程假死、网络波动导致 ACK 丢失，或者个别异常消息导致消费者反复重试卡住。

另外，如果使用手动 ACK 但处理逻辑耗时过长导致心跳超时，连接可能关闭，未 ACK 消息会重新入队。自动 ACK 模式下消费者崩溃则会导致消息丢失，需谨慎使用。

分步处理

1. 确认积压范围

使用管理页面或命令行查看具体哪个队列积压。如果是所有队列都积压，可能是 broker 性能瓶颈或网络问题；如果是单个队列，通常是消费逻辑问题。

2. 检查消费者日志

查看消费者应用日志，搜索 "timeout"、"connection closed" 或业务异常堆栈。确认是否有特定消息导致处理失败并无限重试。

3. 调整预取计数（QoS）

在消费者端设置 basic.qos 的 prefetch_count。如果设置为 1，消费者处理完一条才拿下一条，安全性高但并发低；适当调大（如 10-50）可提升吞吐，但需确保消费者内存足够。

Spring Boot 配置示例：

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

Java 原生客户端示例：

channel.basicQos(10);
channel.basicConsume(queueName, false, consumer); // false 表示手动 ACK

4. 扩容消费者实例

增加消费者进程数量或实例数。确保队列没有设置单例消费限制。如果是集群环境，确保消费者能连接到不同节点。

5. 处理异常消息（死信队列）

对于始终处理失败的消息，配置 TTL（生存时间）和死信交换机（DLX）。当消息重试次数过多或过期后，自动转入死信队列，避免阻塞正常消息消费。

死信队列策略配置命令：

rabbitmqctl set_policy dlx-policy "^queue_name" '{"dead-letter-exchange":"dlx.exchange","message-ttl":60000}' `--apply-to` queues

怎么验证是否生效

1. 监控队列的 messages_ready 数值是否持续下降。

2. 检查消费者端的 ACK 耗时监控，确认平均处理时间是否稳定。

3. 观察 broker 节点的内存和 CPU 使用率，确保没有因连接数激增导致资源耗尽。

Prometheus 监控查询示例：

rabbitmq_queue_messages_ready{queue="your_queue_name"}
rabbitmq_queue_consumers{queue="your_queue_name"}

常见坑

1. 无限重试循环： 消费者捕获异常后重新入队但没有重试次数限制，导致一条坏消息无限消费。建议配合死信队列使用。

2. 预取过大： prefetch_count 设置过大可能导致消费者内存溢出（OOM），尤其是消息体较大时。

3. 自动 ACK 陷阱： 使用自动 ACK 时，一旦消费者崩溃，消息会丢失。建议改为手动 ACK，确保处理成功后再确认。

参考来源

1. RabbitMQ 官方文档 - Consumer Prefetch: https://www.rabbitmq.com/consumer-prefetch.html

2. RabbitMQ 官方文档 - Acknowledgements: https://www.rabbitmq.com/confirms.html

3. RabbitMQ 官方文档 - Dead Letter Exchanges: https://www.rabbitmq.com/dlx.html