使用Spring Kafka向Azure Event Hub发消息遇TimeoutException求助

看起来你遇到的是典型的Kafka生产者超时问题，错误信息Expiring 14 record(s) for eventhubname: 30125 ms has passed since batch creation plus linger time说明生产者在创建消息批次后，加上linger等待时间，超过了请求超时时间仍未收到Event Hub的ACK，最终触发了超时异常。结合你的场景（定时任务+@Async发送80-100条消息，前几次成功后失败），我整理了几个关键的排查和解决方向：

1. 修复@Async线程池的并发问题 #

你用@Async标记发送方法，默认情况下Spring会使用SimpleAsyncTaskExecutor——这个执行器会为每个异步请求创建新线程。当定时任务每小时执行一次，前几次可能资源还充足，但随着线程积累（或者短时间内并发发送80-100条消息），会导致Kafka生产者的IO线程被占满，网络连接数耗尽，消息发送延迟逐渐升高，最终触发超时。

解决方案：
自定义一个线程池来控制并发数，避免无限制创建线程：

@Configuration
@EnableAsync
public class AsyncConfig {
    @Bean(name = "kafkaSenderExecutor")
    public Executor kafkaSenderExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(5); // 根据你的Event Hub分区数和吞吐量调整，比如等于分区数
        executor.setMaxPoolSize(10);
        executor.setQueueCapacity(20);
        executor.setThreadNamePrefix("KafkaSender-");
        executor.initialize();
        return executor;
    }
}

然后修改发送方法指定线程池：

@Async("kafkaSenderExecutor")
protected void send() { 
    kafkatemplate.send(record); 
}

同时，配合Kafka生产者配置max.in.flight.requests.per.connection，建议设置为5左右，避免单个连接上的请求过多导致阻塞。

2. 调整Kafka生产者的超时相关配置 #

你的错误里的30125ms刚好接近默认的request.timeout.ms（30000ms），说明消息在发送过程中，Event Hub返回ACK的时间超过了这个阈值。

关键配置调整：

// 调大请求超时时间，给Event Hub足够的响应时间
props.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, "60000");
// 消息投递总超时时间，要大于request.timeout * (retries + 1)
props.put(ProducerConfig.DELIVERY_TIMEOUT_MS_CONFIG, "180000");
// 关闭linger（如果不需要批次优化），避免等待凑批次导致超时
props.put(ProducerConfig.LINGER_MS_CONFIG, "0");
// 调整重试间隔，避免频繁重试加重负载
props.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, "1000");

解释：delivery.timeout.ms是消息从创建到最终失败的总时间，必须大于request.timeout.ms乘以重试次数+1，否则重试还没完成就会触发超时。

3. 排查Event Hub的分区热点和吞吐量限制 #

Azure Event Hub的性能和分区分布密切相关：

• 如果你的消息key分布不均匀，会导致某个分区的消息量远大于其他分区，形成热点，该分区的处理能力不足会导致ACK延迟。
• 另外，Event Hub有吞吐量单位（TU）的限制，每个TU提供1MB/s的入站吞吐量，如果你的发送量超过了当前TU的上限，会被限流，导致消息延迟。

解决方案：

• 登录Azure Portal，查看Event Hub的监控指标：
  • 检查Partition Incoming Messages，确认是否有分区的消息量远高于其他分区。如果是，优化消息key的生成逻辑，让key均匀分布，或者不指定key，让Event Hub自动分配分区。
  • 查看Throttled Requests指标，如果有被限流的情况，考虑增加吞吐量单位（TU）。
• 同时，确认Event Hub的消息保留期设置（你已经设为7天）不会影响性能，这个一般没问题，但如果存储压力大也可能间接影响。

4. 升级Spring Kafka版本 #

你使用的Spring Kafka 2.2.3版本比较老旧（对应Kafka客户端2.2.x），这个版本存在一些已知的异步发送问题，比如资源泄漏、超时处理逻辑不完善等。新版本的Spring Kafka（比如2.8.x及以上）修复了很多这类问题，并且对Azure Event Hub的兼容性更好。

解决方案：
根据你的Spring Boot版本，升级到兼容的Spring Kafka版本。比如如果用Spring Boot 2.3.x，可以升级到Spring Kafka 2.5.x；如果是Spring Boot 2.4+，可以升级到2.8.x或更高版本。

5. 优化消息发送逻辑 #

虽然你是单条发送，但可以考虑批量发送（如果业务允许），减少网络请求次数，提升效率。比如把80-100条消息分成几个批次发送，而不是每条单独发送，这样可以降低生产者的负载。

示例代码：

@Async("kafkaSenderExecutor")
protected void sendBatch(List<ProducerRecord<String, String>> records) {
    kafkaTemplate.send(records);
}

总结一下：先从线程池和超时配置入手调整，然后排查Event Hub的监控指标，最后考虑升级版本。这些步骤应该能解决你遇到的超时问题。

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