RocketMQ并发两估算

RocketMQMQ

我4个RocketMQ broker，两主两从，采用SYNC_FLUSH/SYNC_MASTER请问大概并发能达到多少，不考虑网速的情况下。硬盘可以每秒写入500MB/S。假如只采用SYNC_FLUSH呢。我增加到5主，每主机1从，并发速度可以达到多少。

关于并发量能达到多少，这其实没有一个固定的数字，因为它取决于一个“短板效应”：最终极限取决于网络IO、磁盘IO、CPU处理能力以及你配置的数据可靠性等级这几者中最慢的那一个。

⚙️ 核心概念：两个层面的“同步”和它们的代价

需要先区分两个关键概念，它们协同决定了系统的性能和可靠性：

1. 同步刷盘 (SYNC_FLUSH)：这是 Broker自身 将消息从内存缓存（PageCache）写入物理磁盘的方式。同步刷盘要求消息必须落盘后才返回成功，这是最可靠的持久化方式，但会明显降低性能。
2. 同步复制 (SYNC_MASTER)：这是 Master和Slave之间 的数据同步方式。同步复制要求消息不仅Master写成功，Slave也必须同步写入成功后，才返回给生产者成功状态，保证了数据的高可用，但同样会带来性能损耗。

场景一：2主2从，SYNC_FLUSH + SYNC_MASTER（你最关心的情况）

这是可靠性最高的配置，但性能损耗也最大。

• 性能损耗估算：参考RocketMQ官方对比数据，同步复制（SYNC_MASTER）相比异步复制，性能会低约10%。而同步刷盘（SYNC_FLUSH）由于强制每次写入都落盘，性能损耗会更高，可能达到20%-30% 甚至更多。综合来看，相比异步刷盘+异步复制的组合，你的这套配置性能可能会下降30%-50% 左右。

• 一个参考基准：有一份在8核16G、本地磁盘环境下的压测数据显示，在未明确指定是同步还是异步策略下，单机TPS（每秒处理消息数）可以跑到 1.8万 - 2.2万 左右。

  • 这是一个很好的基准值。结合你500MB/S的磁盘写入能力（远高于测试环境），磁盘不是瓶颈。你的瓶颈将主要来自同步复制带来的网络往返延迟和同步刷盘带来的磁盘IOPS（每秒输入输出操作次数）压力。

• 并发估算：综合上述信息，对于你的2主2从，采用最严格的 SYNC_FLUSH + SYNC_MASTER 配置，单机写入TPS的一个合理估算区间可能在 1万 - 1.5万 条/秒左右。消息越小，这个数值可能越高。两台Master合计，集群总TPS可能在 2万 - 3万 条/秒这个量级。

场景二：2主2从，仅采用 SYNC_FLUSH（Slave异步复制）

如果只采用同步刷盘，但主从复制是异步的（ASYNC_MASTER），那么性能会有明显提升。

• 估算逻辑：去掉了最耗时的“等待Slave确认”环节，消息成功写入Master内存并刷盘后即可返回。这个配置下，同步刷盘依然是主要性能瓶颈，但整体吞吐量会比场景一高。
• 估算范围：集群总TPS保守估计可以达到 3万 - 5万 条/秒或更高。这个配置也是业界常推荐的平衡方案：“同步刷盘保证单机数据不丢，异步复制保证高可用性”。

场景三：5主，每主1从（增加Master数量）

这是通过水平扩展来提升性能。

• 估算逻辑：在理想情况下，集群的总吞吐量约等于各Master节点的吞吐量之和。增加了Master节点，意味着可以并行处理更多的写入请求。
• 估算范围：理论上，5个Master提供的总写入能力是2个Master的2.5倍。如果场景一中单Master TPS约为1万-1.5万，那么5主集群的总TPS上限有望达到 5万 - 7.5万 条/秒。

📊 总结对比表

💡 给你的建议

1. 先明确业务需求：数据是否真的“一条都不能丢”？如果业务可以容忍极端情况下（如Broker同时宕机且磁盘损坏）丢失极少量数据，异步复制（ASYNC_MASTER）+ 同步刷盘（SYNC_FLUSH） 是更经济且性能更好的选择。
2. 压测是唯一标准：估算终究是估算。最可靠的方式是针对你的业务场景（消息大小、Topic数量、并发线程数等）进行一次实际的压力测试。压测数据能提供非常有价值的参考。
3. 优化其他环节：除了Broker配置，生产者端的批量发送、异步发送方式，以及客户端的消费能力，都会影响整体吞吐量。

本文由 创作，采用 知识共享署名4.0 国际许可协议进行许可。本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名。最后编辑时间为: 2026/07/30 08:57