理解Kafka Producer Metrics：request_rate高于record_send_rate问题咨询

你的指标解读核心逻辑是正确的：

单Topic生产场景下，批量发送机制正常生效时，producer.request_rate（生产者发往Broker的总请求速率）必然低于producer.topic.record_send_rate（单条消息生产速率），因为单个Produce请求会打包同分区的多条批量消息。你观测到请求速率反超消息发送速率，确实属于不符合预期的异常现象。

异常常见成因 #

• 控制类请求拉高总请求速率：producer.request_rate统计的是所有发往Broker的请求，不止是消息生产的ProduceRequest，还包含元数据拉取请求、事务控制请求、API版本协商请求等。如果集群有频繁的Topic分区变更、副本迁移，或者生产者配置的metadata.max.age.ms（元数据过期时间）过小，都会导致高频发送控制请求，拉高整体请求速率。
• 批量发送完全失效：如果单条消息大小接近甚至超过默认16KB的batch.size，每条消息只能单独成批，此时Produce请求数会和消息数持平；如果再开启了重试机制，发送失败的请求重试也会被统计进请求速率，就会出现请求数反超消息数的情况。
• 分区数与生产并发不匹配：如果Topic分区数远大于生产者的生产并发度，每个分区的消息量都不足以在100ms的linger.ms周期内攒满16KB的批次，到期后每个分区的小批次都会单独发送请求，也会导致总请求数偏高。

优化建议 #

不要直接调整批量大小配置，先按以下优先级排查：

1. 先统计生产者请求类型分布，确认非Produce类请求的占比，如果是元数据请求过多，优先调大metadata.max.age.ms到10~30分钟，同时排查集群侧是否有频繁的元数据变更操作。
2. 如果确认都是ProduceRequest占比过高，先统计单条消息大小：
   • 单条消息大于16KB的场景，将batch.size调整为单条消息大小的2~3倍即可
   • 单条消息很小的场景，可适当调大linger.ms到200_{300ms，或者将`batch.size`调整到32KB}64KB，给每个分区的批次留出足够的攒批空间

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