perf-test高并发压测核心是合理控制连接、信道、队列生命周期和确认机制：用--producers 50 --producer-channel-count 10替代-x 500，显式声明exchange/queue并绑定，启用--confirm与--multi-ack-every 100，监控unacked、延迟及确认积压而非仅tps。
直接用 perf-test 做高并发压测，核心不是堆参数，而是控制好连接、信道、队列生命周期和确认机制——否则很容易在 1000+ 生产者时卡死在连接建立阶段或触发 RabbitMQ 的 connection flood protection。
避免连接数爆炸：用 --producers 而非 -x 控制并发量
-x（即 --producers）看似是“生产者数量”，但实际每开一个生产者就会新建一个 TCP 连接 + 多个信道。RabbitMQ 默认限制单 IP 最多 65535 个连接，而 Linux 系统本身也有 ulimit -n 限制（常为 1024）。真实压测中，-x 500 很可能直接失败，报错 java.net.SocketException: Too many open files 或 RabbitMQ 日志里出现 connection_closed_abruptly。
实操建议：
- 优先用
--producers 50 --producer-channel-count 10：50 个连接，每个连接内开 10 个信道，共 500 个逻辑生产者，连接数可控 - 配合
--connection-timeout 30000防止连接卡住拖垮整个测试 - 若必须高连接数，先在压测机上调大
ulimit -n 65536，并在 RabbitMQadvanced.config中调高max_connections
队列声明与绑定必须显式指定 --exchange 和 --routing-key
默认 exchange 是 amq.direct，类型为 direct。如果你没传 -e 或 --exchange，又用了 -k（routing key），PerfTest 会尝试向 amq.direct 发送消息，但该 exchange 不一定绑定了你的目标队列——结果就是消息全丢，receiving rate avg: 0 msg/s，但发送速率看起来很高，误判为“性能好”。
常见错误现象：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 压测跑起来后 consumer 完全收不到消息，Web UI 显示 queue 无 ready 消息
- RabbitMQ 日志里有
NOT_FOUND - no exchange 'xxx' in vhost '/'（你指定了 exchange 但没创建）或NO_ROUTE
正确做法：
- 提前在 vhost 里创建好 exchange 和 queue，并完成 binding；或
- 用
--exchange my-exchange --routing-key my.key --queue my-queue --queue-durable true让 PerfTest 自动声明（注意：自动声明只在首次运行生效，重复运行需加--queue-autodelete false防冲突）
消息确认模式决定吞吐上限和数据安全边界
-a（--autoack）看起来能提吞吐，但它绕过所有确认机制：Producer 发完就认为成功，Broker 接收失败、Queue 内存溢出、Consumer crash 都不会反馈。线上环境严禁用它测“真实吞吐”。
真正有意义的高并发压测，应启用 publisher confirms：
- 加
--confirm启用发布确认（默认每条 confirm，慢但安全） - 加
--multi-ack-every 100改为批量确认，吞吐可提升 3–5 倍，同时仍保证不丢 - 务必配
--confirm-timeout 30，防止某条消息卡住整条流水线 - 如果看到日志频繁出现
unconfirmed publishes timeout，说明 Broker 已过载，不是客户端问题
监控指标比“平均 TPS”更有诊断价值
终端输出的 sending rate avg: XXX msg/s 是幻觉。它只统计从 JVM 发出的速率，不反映 Broker 实际落盘、Consumer 拉取、网络抖动等环节。真正要盯的是：
- RabbitMQ Web UI 的
Ready/Unacked/Total柱状图：如果Unacked持续上涨，说明 Consumer 处理不过来或 autoack 关了但没手动 ack - PerfTest 自带的 latency 输出：
min/median/95th/99th consumer latency—— 99th > 500ms 就得查 Consumer GC 或网络延迟 - 用
--metrics-prometheus --metrics-prometheus-port 8090对接 Prometheus，重点关注rabbitmq_perf_test_published_total和rabbitmq_perf_test_confirmed_total的差值，差值大 = 确认积压
别只盯着数字涨没涨；当 --producers 200 时 TPS 反而比 100 低，大概率是 connection recovery 频繁触发，或者磁盘 I/O 成瓶颈——这时候看 iostat -x 1 比改参数更管用。
