这个问题我之前也碰到过，核心原因是你混淆了retries参数的作用——它管的是消息发送失败后的重试次数，而不是元数据获取失败的重试逻辑。Kafka生产者默认会持续重试获取元数据，直到成功或者遇到不可恢复的错误，这就是为什么你会看到无限打印日志的原因。下面给你几个可行的解决方案：

1. 调整max.block.ms限制元数据等待时长 #

max.block.ms是生产者在发送消息时，阻塞等待元数据加载完成的最大时间，默认值是9223372036854775807（相当于无限等待）。你可以把它设置为一个合理的超时值，比如30秒，超过这个时间后生产者会抛出TimeoutException，终止元数据重试逻辑。

修改你的生产者配置：

max.block.ms = 30000  # 30秒后超时停止等待元数据

配合metadata.max.age.ms（元数据刷新间隔），就能有效避免无限重试的情况。

2. 发送前主动检查主题是否存在 #

在发送消息前，用KafkaAdminClient主动校验目标主题是否存在，如果不存在就直接处理错误，避免进入元数据重试循环。

示例Java代码：

import org.apache.kafka.clients.admin.AdminClient;
import org.apache.kafka.clients.admin.AdminClientConfig;
import org.apache.kafka.clients.admin.ListTopicsResult;

import java.util.Properties;
import java.util.Set;
import java.util.concurrent.ExecutionException;

public class TopicValidator {
    public static boolean isTopicExist(String bootstrapServers, String targetTopic) throws ExecutionException, InterruptedException {
        Properties adminProps = new Properties();
        adminProps.put(AdminClientConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);
        
        try (AdminClient adminClient = AdminClient.create(adminProps)) {
            Set<String> existingTopics = adminClient.listTopics().names().get();
            return existingTopics.contains(targetTopic);
        }
    }
}

在发送消息前调用这个方法，返回false时直接抛出异常或终止流程，就不会触发后续的元数据重试了。

3. 优化重连参数减少日志频率（可选） #

如果暂时不想中止重试，但希望减少日志输出，可以调整重连间隔参数：

• reconnect.backoff.ms：初始重连间隔，默认50ms
• reconnect.backoff.max.ms：最大重连间隔，默认1000ms

你可以把reconnect.backoff.max.ms调大，比如设为5000ms，这样每次重试的间隔会逐渐拉长，日志输出频率会降低，但这不能彻底中止重试，还是需要配合max.block.ms才能解决根本问题。

再明确一下：retries仅作用于消息发送阶段的可重试错误（比如网络波动、leader节点不可用等），而元数据获取是发送消息前的前置准备步骤，这个阶段的重试逻辑完全不受retries参数控制，所以你设置retries=5不会影响元数据的重试行为。

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