AWS MSK：Kafka生产者吞吐量与分区数关系的实验异常原因问询

先明确你的测试核心参数：

kafka-producer-perf-test --num-records 12000000 --throughput -1 --acks=1 --linger.ms=100 --buffer.memory=5242880 --compression.type=none --request.timeout.ms=30000 --record-size 1000

其中acks=1、linger.ms=100、buffer.memory=5MB这三个参数是解释实验现象的关键。

一、3 Broker场景：2分区/节点性能低于1分区/节点的原因 #

• 单节点资源瓶颈与复制流量抢占
  3个节点时，每个节点承载2个分区（总6分区），既要作为这2个分区的leader处理生产者写入，又要作为其他分区的follower同步数据。集群总带宽有限，节点间的复制流量会抢占生产者写入的可用带宽，导致单节点的网络、磁盘IO提前饱和。相比1分区/节点（总3分区），每个节点负载翻倍，但集群资源并未同步翻倍，内部复制的额外开销直接抵消了分区并行带来的收益。

• 缓冲区分散导致批次效率下降
  5MB的发送缓冲区由所有分区共享，6个分区平均每个仅能分到约833KB。单条记录大小为1000字节，每个分区最多攒833条就会占满缓冲区，再加上linger.ms=100的时间限制，很难攒出足够大的批次。小批次会让生产者发送请求的频次大幅增加，TCP连接开销、Kafka协议请求头的占比被放大，最终拉低整体吞吐量。

• 单节点多分区的写入额外开销
  同一个Broker上的多个分区写入时，即便Kafka是顺序写，也需要在多个日志文件间切换，带来额外的磁盘寻址开销。3节点场景下这种开销集中在少数节点，进一步降低了写入效率。

二、9 Broker场景：3分区/节点性能高于1分区/节点的原因 #

• 集群资源与并行度匹配
  9个节点时，每个节点承载3个分区（总27分区），节点数和分区数同步增长（均为原来的3倍）。每个节点的负载处于合理范围，集群总带宽、磁盘IO能够支撑更高的并行写入。同时，复制流量被分散在更多节点之间，不会出现3节点场景中互相抢占带宽的情况，生产者的写入带宽得以充分利用。

• 并行度收益抵消批次开销
  虽然27个分区会让每个分区的缓冲区配额进一步降低（约185KB/分区），但27个分区的并行发送能力带来的总吞吐量提升，完全覆盖了小批次的开销。Kafka生产者会针对不同分区并行发起写入请求，27个分区的并行度远高于9个分区，整体写入效率被大幅拉高。

• 负载分散后的磁盘效率提升
  9个节点分散了分区负载，每个节点的3个分区写入压力小，磁盘顺序写的连续性更好，几乎没有多分区切换的额外开销，进一步提升了写入性能。

内容的提问来源于stack exchange，提问作者ankur