云服务器
RocketMQ 在生产环境中的性能要求并非一个固定的数值，而是取决于业务场景、硬件配置、消息模型（同步/异步）以及集群规模。不过，在主流互联网生产环境中，通常遵循以下核心性能指标和最佳实践标准：
1. 核心吞吐量指标 (Throughput)
这是衡量 RocketMQ 性能最直观的指标。在标准的单机或集群配置下，业界普遍认可的基准如下：
- 单 Topic 吞吐能力：
- 顺序消息/小消息（< 2KB）：单 Broker 节点通常可支撑 50,000 ~ 100,000 TPS（Transactions Per Second）。
- 批量消息/大消息：受限于网络带宽和磁盘 I/O，TPS 会下降，但总字节数（Bandwidth）是瓶颈。通常单节点可稳定处理 200MB/s ~ 500MB/s 的写入流量。
- 延迟 (Latency)：
- P99 延迟：在正常负载下，端到端延迟（从 Producer 发送成功到 Consumer 拉取）应控制在 毫秒级（通常 < 10ms 为优秀，< 50ms 为合格）。
- 刷盘策略影响：若使用
SYNC_FLUSH（同步刷盘），延迟会显著增加且抖动较大；生产环境推荐默认使用ASYNC_FLUSH（异步刷盘），此时延迟极低，可靠性通过多副本机制保障。
2. 硬件资源基线要求
为了达到上述性能，生产环境的硬件配置建议如下（以 4C8G 或 8C16G 为例）：
| 组件 | 推荐配置 | 关键原因 |
|---|---|---|
| CPU | 4核 ~ 8核 | RocketMQ 主要消耗 CPU 在序列化/反序列化及网络 IO 处理。高并发下需避免 CPU 软中断过高。 |
| 内存 | 16GB ~ 32GB | 用于 PageCache（文件系统缓存）。内存越大，PageCache 命中率越高，写性能越接近内存速度。 严禁开启 Swap。 |
| 磁盘 | SSD/NVMe (必选) | 机械硬盘 (HDD) 仅适用于冷数据归档或极低频场景。 生产环境必须使用 SSD，否则随机写 IOPS 会成为巨大瓶颈，导致 TP 大幅下降。 |
| 网络 | 万兆 (10GbE) | 消息体较大时，千兆网卡极易成为瓶颈。集群内部通信（Broker-Broker, NameServer-Broker）建议万兆。 |
3. 架构与部署层面的性能要求
单纯提升单机性能有上限，生产环境更依赖架构设计来保证高性能和高可用：
- 多副本机制 (Replication)：
- 生产环境必须开启主从复制（Master-Slave），通常配置为 2 副本（一主一从）或 3 副本（多活）。
- 性能权衡：开启同步复制（Sync Replication）会增加写入延迟约 20%-30%，但能确保零数据丢失。大多数场景推荐 异步复制 + 自动故障转移。
- Topic 分区数 (Queue 数量)：
- 为了充分利用多 Broker 和多消费者的并行处理能力，每个 Topic 的 Queue 数量建议设置为 物理机 CPU 核数的 2-4 倍，或者根据预估的峰值 TPS 动态调整。
- 过少的 Queue 会导致消费者无法水平扩展，造成单点瓶颈。
- 消息大小控制：
- 黄金法则：单条消息建议控制在 128KB 以内，理想大小为 1KB ~ 10KB。
- 超大消息（如 > 1MB）会严重阻塞磁盘 I/O 和网络传输，导致“长尾延迟”，甚至拖垮整个 Broker。对于大文件，应上传对象存储（OSS/S3），仅传递 URL。
4. 监控与调优关键点
在生产环境中，除了看 TPS，还需关注以下指标来判断性能是否达标：
- CommitLog 刷盘耗时：如果刷盘耗时持续超过 10ms，说明磁盘 I/O 压力大或配置不当。
- PageCache 命中率：通过
vmstat或操作系统工具查看，生产环境应保持在 95% 以上。 - Consumer Lag (消费积压)：虽然不直接代表 Broker 性能，但巨大的积压往往意味着 Consumer 处理能力不足或 Broker 推送机制受阻。
- GC 频率：JVM 频繁 Full GC 会导致 Broker 暂停（STW），严重影响性能。建议开启 G1 垃圾回收器并合理设置堆内存（通常为物理内存的 50%-70%）。
总结
在典型的生产环境中，一个配置合理的 RocketMQ 集群（使用 SSD、万兆网络、4 副本架构）应能满足：
- 单节点写入：> 5 万 TPS。
- 端到端延迟：< 10ms (P99)。
- 稳定性：支持海量消息堆积而不崩溃，具备秒级故障切换能力。
如果您的业务场景对实时性要求极高（微秒级）或吞吐量极大（千万级 TPS），则可能需要考虑分片更多、专门优化的云原生方案，或者评估是否真的需要如此高的实时性。