从你描述的情况来看，Kafka在启动Spring Boot服务后一段时间内宕机，同时Debezium和Spring Boot客户端都持续抛出无法连接Broker的警告，结合你仅修改了数据库和IP配置的背景，我整理了几个优先级较高的排查方向：

1. 检查Kafka Broker的内存配置 #

默认的Kafka启动脚本（kafka-server-start.sh）里的JVM内存参数可能不足以支撑新增的客户端负载（Debezium连接器+Spring Boot消费者）：

• 打开kafka-server-start.sh，找到KAFKA_HEAP_OPTS配置，默认通常是-Xmx1G -Xms1G，如果你的服务器内存充足，建议调整为-Xmx4G -Xms4G（具体数值根据服务器物理内存调整，一般不要超过物理内存的50%）
• 修改后重启Kafka，观察是否还会出现宕机情况

2. 验证Kafka的监听地址配置 #

你修改了IP配置，可能存在Broker绑定地址与客户端连接地址不匹配的问题：

• 检查server.properties里的两个核心配置：
  • listeners：Broker实际监听的地址，建议设置为PLAINTEXT://0.0.0.0:9092（允许所有网卡接入）
  • advertised.listeners：Broker对外暴露给客户端的地址，必须是客户端能正常访问到的IP/域名，比如PLAINTEXT://vsi-kafka-dev-01.c.presence-ss.internal:9092或者PLAINTEXT://10.128.15.238:9092
• 如果这两个配置不匹配，会导致客户端连接异常，甚至触发Broker因处理无效连接过载宕机

3. 查看Kafka宕机时的核心日志 #

Kafka宕机时，logs/server.log里会记录具体的错误原因，这是定位问题最关键的依据：

• 搜索日志中的ERROR级别信息，重点关注：
  • 是否出现java.lang.OutOfMemoryError: Java heap space（对应内存不足问题）
  • 是否有与ZooKeeper断开连接的日志（比如Connection to ZK server timed out，需排查ZooKeeper稳定性）
  • 是否存在SocketException类的网络端口异常

4. 检查客户端的连接与负载参数 #

Spring Boot和Debezium的客户端配置可能存在过度消耗Broker资源的情况：

• Spring Boot消费者：检查application.yml/application.properties中的spring.kafka.consumer.max-poll-records、spring.kafka.consumer.concurrency参数，避免一次性拉取过多消息导致Broker负载过高
• Debezium连接器：检查连接器配置中的max.batch.size、poll.interval.ms参数，避免高频率、大批量的数据同步给Broker带来压力

5. 验证服务器的系统资源限制 #

客户端连接后，服务器的文件句柄、端口资源可能被耗尽：

• 执行ulimit -n查看系统文件句柄限制，Kafka需要足够的文件句柄处理连接和日志文件，建议设置为65535以上
• 执行netstat -an | grep 9092 | wc -l查看当前Kafka端口的连接数，如果连接数远超预期，可能存在客户端连接泄漏问题

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