Kafka生产者消息发布超时问题排查求助

问题现象 #

org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for "topic_namexxxx" -4: 96866 ms has passed since batch creation plus linger time
Producer Fails to Publish Messages

已尝试调整批量大小（batch.size）和超时时间相关参数，当前生产者核心配置如下：

Map<String, Object> props = new HashMap<>();
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress);
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);
props.put(ProducerConfig.MAX_REQUEST_SIZE_CONFIG, "10485880"); //10MB
props.put(ProducerConfig.BATCH_SIZE_CONFIG, Integer.toString(524288)); //0.5MiB
props.put(ProducerConfig.LINGER_MS_CONFIG, "100"); //100 ms
props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, "66554432"); //64MB
props.put(ProducerConfig.MAX_BLOCK_MS_CONFIG, "120000"); //120s
props.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, "90000"); //90s
props.put(ProducerConfig.ACKS_CONFIG, "all");

使用Spring KafkaTemplate发送消息：

@Autowired
private KafkaTemplate<String, String> kafkaTemplate;
kafkaTemplate.send(topic, msg);

容器扩缩容是否会引发该超时问题？ #

是的，容器扩缩容可能直接或间接触发这类超时异常，核心原因包括：

• 瞬时消息量突增：扩容后并发请求上涨，生产者短时间内发送大量消息，超出Kafka集群处理能力。由于配置了acks=all，需要所有同步副本确认消息，若broker无法及时处理请求、完成副本同步，会导致生产者等待ACK超时。
• 连接重建开销：扩缩容过程中，新启动的生产者实例需要重新与broker建立连接、获取topic元数据（分区信息、leader节点等），这个过程中消息发送可能被阻塞，若阻塞时间超过request.timeout.ms或max.block.ms就会触发超时。
• 分区负载不均：扩缩容后，若生产者分区分配策略未及时适配，可能导致部分分区被大量生产者实例抢占，broker对应分区处理压力陡增，消息堆积进而引发超时。

额外排查与优化方向 #

除了扩缩容的影响，还可以从以下维度排查优化：

• Broker端瓶颈：检查Kafka broker的CPU、磁盘IO、网络带宽是否过载，尤其是acks=all场景下，副本同步的磁盘IO压力更大。查看broker日志中是否存在UnderReplicatedPartitions或LeaderNotAvailable相关报错。
• 分区数量不足：若topic分区数过少，扩容后的生产者实例无法均匀分摊发送压力，导致单分区消息堆积，broker处理不过来引发超时。可考虑增加topic分区数。
• 补充重试配置：当前未显式设置retries和retry.backoff.ms，遇到瞬时网络波动或broker繁忙时，生产者无重试机制直接触发超时。建议添加合理的重试配置：

  props.put(ProducerConfig.RETRIES_CONFIG, "3");
  props.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, "1000");
  

• 调整linger.ms参数：当前linger.ms=100ms，生产者会等待100ms凑齐batch.size再发送。若消息量不足，会额外增加发送延迟，叠加broker处理慢的情况容易触发超时。可根据实际消息量降低该参数，减少等待时间。

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