rocketmq生产端性能调优需平衡吞吐、延迟与稳定性，核心是复用1～3个producer实例、合理使用异步发送、控制批量大小在500kb～800kb、动态计算batchsize、调整关键参数并规避enabledetailstat开启等常见陷阱。
RocketMQ 生产端消息发送性能调优，核心在于平衡吞吐量、延迟与稳定性。单纯堆高并发或压缩批量大小都容易顾此失彼，真正有效的调优需结合业务特征、网络环境和集群负载做针对性调整。
合理设置 Producer 实例与线程模型
单个 DefaultMQProducer 实例是线程安全的，内部自带异步发送队列和回调线程池，无需为每个线程新建 Producer。滥用多实例反而加剧资源竞争、增加 NameServer 查询压力。
- 推荐一个 JVM 进程内复用 1～3 个 Producer 实例，按 Topic 或业务域隔离（如订单类、日志类分开）
- 避免在循环中反复调用 send() 同步方法；高吞吐场景优先走 sendAsync() 或 sendOneway()（注意可靠性取舍）
- 异步发送时，sendCallback 回调逻辑必须轻量，避免阻塞或耗时操作（如 DB 写入、远程调用），否则会拖慢内部回调线程池
批量发送不是越大越好
批量（Batch）能显著降低网络 RTT 和 Broker 解包开销，但过大的 batch 容易触发内存溢出、网络分片或单条失败导致整批重试。
- 默认单条消息限制 4MB，批量总大小建议控制在 1MB 以内（实测 500KB～800KB 平衡性最佳）
- 批量消息数不宜硬编码，应根据平均单条大小动态计算：batchSize = min(100, 1_000_000 / avgMsgSize)
- 同一 batch 内所有消息必须属于同一 Topic、同一 Queue（即不能跨队列聚合），否则会自动拆分，反而增加开销
关键参数调优要点
以下参数直接影响发送链路响应与资源占用，需结合压测结果微调：
- sendMsgTimeout：默认 3s，若网络抖动频繁可适度放宽至 5s，避免误判超时引发重试风暴
- retryTimesWhenSendFailed：同步发送默认重试 2 次（共 3 次尝试），生产环境建议设为 0 或 1，依赖上游幂等+下游重试更可控
- compressMsgBodyOverHowmuch：消息体超过该阈值（默认 4KB）自动压缩，CPU 允许前提下建议调低至 1KB，对文本类消息压缩率可观
- rocketmq.client.asyncSenderThreadPoolQueueCapacity：异步发送队列容量，默认 50000，若 Callback 处理慢且并发高，需适当增大防丢弃
规避常见性能陷阱
很多性能问题源于配置或使用方式的细节疏忽：
- 未关闭 enableDetailStat（默认 true）：开启后会采集每条消息的耗时统计，高频场景下带来明显 CPU 开销，线上务必设为 false
- 频繁调用 createTopic：每次创建都会触发 Broker 元数据更新，应提前预建 Topic，或通过运维平台统一管理
- 消息 Key 未设置或重复：Broker 索引依赖 Key，缺失 Key 会导致无法按 Key 查询；Key 冲突则影响顺序消费和重试定位，建议用唯一业务 ID（如 order_id + timestamp）
- 忽略 waitStoreMsgOK 参数语义：设为 false 可跳过刷盘确认（仅适用于允许少量丢失的场景），但会提升吞吐，需明确业务容忍度
调优不是一劳永逸的事。随着流量增长、Broker 升级或网络架构变化，定期用 mqadmin statsAll 查看发送成功率、RT 分布和重试率，再结合应用侧 GC 日志与线程 dump，才能持续保障消息链路高效稳定。
