核心是通过手动签收（autoAck=false）与QoS预取限制（prefetchCount）实现消费端主动控量，确保“处理一条、确认一条、再给一条”；必须禁用自动确认，否则basicQos无效；prefetchCount需按场景设为1～20，配合监控unacked消息数防阻塞。

核心是让 RabbitMQ 别一股脑把消息全推给消费者，而是“处理一条、确认一条、再给一条”。这靠的是 手动签收 + QoS 预取限制，不是在生产端压速度，而是在消费端主动控量。

必须关闭自动确认

这是所有限流生效的前提。autoAck=true 时，RabbitMQ 一发消息就认为成功，basicQos 完全无效。

• 原生客户端：调用 channel.basicConsume(queue, false, consumer)，第二个参数传 false
• Spring AMQP：配置 acknowledge-mode: manual，不能用 auto 或 none
• 不设手动确认，后面所有限流配置都白搭

设置合理的预取值（prefetchCount）

它定义了每个消费者最多能持有几条“已投递但未确认”的消息。值越小，节奏越稳，系统越安全。

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 保守场景（如耗时长、内存敏感）：设为 1，即一次只处理 1 条，确认完才拿下一条
• 中等吞吐场景：可设为 5 或 10，需结合单条处理耗时和 JVM 堆内存评估
• 注意：prefetch 是 per-consumer 级别（global=false），不是整个应用或 channel 共享

Spring Boot 中的推荐配置方式

比硬编码更清晰、易维护，也方便环境差异化。

• application.yml 中统一配置： spring:
    rabbitmq:
      listener:
        simple:
          acknowledge-mode: manual
          prefetch: 1
          concurrency: 3
• 消费者方法里显式签收： channel.basicAck(message.getMessageProperties().getDeliveryTag(), false)
• 异常时别漏处理：捕获后调用 basicNack 或 basicReject，避免 unacked 消息堆积卡死

必须监控和防住的几个关键点

配了不等于万事大吉，运行中要盯住真实状态。

• 查管理界面或 API 的 messages_unacknowledged 数：持续高位说明限流没起效，或消费逻辑阻塞/超时太久
• 业务处理不能长期阻塞：比如同步调用外部接口超时未设、数据库锁等待过长，都会导致 ACK 延迟，占满 prefetch 窗口
• 别盲目调高 prefetch：单消费者撑不住时，优先加消费者实例数（提高 concurrency），而不是把 prefetch 改成 50、100