性能基准与调优
本章提供 RabbitMQ 不同配置下的性能基准数据，以及调优方法论。
下面这些数字是未经实测验证的示例数量级，仅用于建立数量级直觉，不代表 RabbitMQ 在任何环境下的真实性能，也不应作为容量规划的输入。做容量规划前，必须用 PerfTest 在自己的环境复现；不同硬件、消息大小、网络条件、持久化与确认策略下，吞吐量差异可达数倍。
1. 测试环境
| 配置 | 说明 |
|---|---|
| 机器 | 4C8G SSD |
| 网络 | 同机房内网 |
| RabbitMQ | 3.12 |
| Java | 17 |
| 消息大小 | 1KB |
2. 性能基准
2.1 生产者
| 队列类型 | 逐条等待 Confirm | 异步 Confirm | 批量等待 Confirm |
|---|---|---|---|
| Classic Queue | 2,000 msg/s | 25,000 msg/s | 40,000 msg/s |
| Quorum Queue | 1,500 msg/s | 10,000 msg/s | 15,000 msg/s |
| Stream Queue | 5,000 msg/s | 50,000 msg/s | 100,000 msg/s |
异步 Confirm 指客户端异步接收确认，批量等待指让多条消息同时处于未确认状态后再等待结果。二者是客户端组织确认的方式，可以配合使用，并非 RabbitMQ 提供的独立批量 Confirm 协议。表中数字为示意性的数量级示例，不附带实测依据。
2.2 消费者
| 队列类型 | prefetch=1 | prefetch=10 | prefetch=100 |
|---|---|---|---|
| Classic Queue | 1,000 msg/s | 10,000 msg/s | 20,000 msg/s |
| Quorum Queue | 800 msg/s | 8,000 msg/s | 12,000 msg/s |
| Stream Queue | 5,000 msg/s | 50,000 msg/s | 100,000 msg/s |
prefetch 约束的是未确认投递数，不是吞吐量的直接计算公式；其作用范围还受 QoS 配置影响（是否全局限制）。实际消费速率取决于消息处理耗时、确认方式（自动或手动）和并发模型，表中数字仅为示意性的数量级示例。
2.3 延迟
| 指标 | 延迟 | 测量边界 |
|---|---|---|
| 发布确认延迟 | 0.1~0.5ms | 发布到收到对应 Publisher Confirm |
| 端到端延迟 | 1~5ms | 发布到消费者收到消息 |
| Quorum 确认延迟 | 2~10ms | 发布到收到 Quorum 对应 Confirm |
表中数值为示意性的数量级示例，不附带统计口径，未覆盖 P95/P99 长尾。真实延迟受持久化、复制与批量落盘影响，需按明确起止事件实测得出，不能直接等同于单次磁盘写入耗时。
3. 调优方法论
3.1 识别瓶颈
排查性能问题时，先对比发布速率、确认速率与消费速率，结合队列积压和资源指标定位瓶颈，而不是把某一现象直接归因到某个配置。
- 发布速率低：检查生产者 CPU、消息序列化、网络、Confirm 延迟与未确认消息数。
- 确认延迟高：检查队列类型、持久化与复制开销，以及 Broker 的 CPU、磁盘与网络。
- 消费速率低：检查消费者数量、业务处理耗时、确认方式、prefetch 与客户端资源。
- 队列持续积压：比较消息进入与离开队列的速率；进入速率长期高于离开速率，积压就会持续增长。
这些现象只能缩小排查范围，不能单独证明某个组件就是瓶颈。调整配置前，应先用指标和对照测试验证判断。
3.2 调优步骤
- 建立基线：固定队列类型、消息大小、持久化与确认策略，记录吞吐量、延迟和资源使用。
- 逐步增加负载：每次只调整一个变量（生产者数量、消费者数量或 prefetch），避免同时改动多个参数。
- 观察变化：记录吞吐量是否增长、延迟是否恶化，以及 CPU、内存、磁盘、网络的变化。
- 定位瓶颈：结合客户端与 Broker 指标，区分客户端处理能力、网络、磁盘 I/O、队列处理与业务逻辑。
- 复测验证：对候选配置重复测试，在接近目标生产负载下验证吞吐量、延迟与资源余量。
吞吐量不再增长时，先结合第 4 步的指标确认限制来自客户端、Broker、网络、磁盘 I/O 还是下游业务，再决定是否继续加并发；测试结论要同时看吞吐量、延迟和资源使用，不能只追求峰值。
4. 常见调优项
| 项目 | 调优方向 |
|---|---|
| 生产者 | 异步处理 Confirm，按确认延迟与内存占用调整未确认消息上限 |
| 队列 | 根据吞吐量、持久化、消费语义与运维成本选择队列类型 |
| 消费者 | 按处理耗时与确认方式调整 prefetch，必要时增加消费者 |
| 消息 | 按网络带宽、CPU 与消息体积评估压缩和序列化格式 |
| 连接 | 复用连接与 Channel，避免频繁创建关闭；注意客户端对 Channel 并发使用的约束 |
| Broker | 先定位资源瓶颈，再有针对性地调整内存、磁盘与 TCP 参数 |
5. 性能陷阱
| 陷阱 | 说明 |
|---|---|
| 逐条等待 Confirm | 每条消息都等确认再发下一条，吞吐量受确认往返延迟限制；低吞吐场景下可能是合理的简单选择 |
| prefetch=1 | 限制未确认投递数量，处理耗时较长时无法充分利用消费者；耗时极短或需限制在途消息时反而合适 |
| 大消息 | 提高网络传输、复制、客户端缓存与存储开销；是否压缩取决于可压缩性与 CPU 成本 |
| 频繁声明 | 在每条消息处理路径重复声明交换器/队列，应在启动阶段完成声明 |
| 消息堆积 | 进入速率持续高于消费速率时积压增长，增加内存、磁盘与恢复成本，需结合队列类型评估 |
| 事务 | AMQP 事务与 Publisher Confirm 语义不同，事务需要额外的提交往返，吞吐量通常显著低于 Publisher Confirm；仅在需要事务语义时使用 |