Spring Boot Kafka应用突发停止接收消息问题排查求助

针对你遇到的这个Kafka消费者突然停服、无任何报错且几小时后自动恢复的棘手问题，结合你使用的Spring Boot 1.5.4.RELEASE、spring-kafka-1.1.6和kafka-clients-0.10.1.1版本，我整理了几个重点排查方向，你可以逐一验证：

• 检查极端的超时配置
  你配置的SESSION_TIMEOUT_MS_CONFIG=30ms和zookeeper.session.timeout=400ms都远低于Kafka的默认值（分别是30000ms和6000ms）。这么短的超时时间很容易引发问题：

  • 消费者的心跳来不及发送，被Broker判定为“死亡”并踢出消费组，但由于自动提交开启，可能不会输出明显的重平衡日志；
  • ZooKeeper连接稍有延迟就会导致消费者失去元数据同步能力，无法发现新的消息或分区。
    建议先把这两个参数调整为默认值或更合理的范围（比如session timeout设为30000ms，zookeeper session timeout设为6000ms），观察是否还会出现问题。

• 分析自动提交配置的影响
  你开启了ENABLE_AUTO_COMMIT_CONFIG=true且AUTO_COMMIT_INTERVAL_MS_CONFIG=1ms，这会导致消费者每秒提交1000次offset，给Broker带来极大的压力。在企业级集群中，Broker可能会对高频请求做限流或静默丢弃处理，导致消费者无法正常提交offset，但旧版本的kafka-clients-0.10.1.1可能不会将这类提交失败的异常抛出到应用层，最终表现为消费者停止拉取消息。
  建议将自动提交间隔调整为更合理的值（比如1000ms），或者改为手动提交offset（结合@KafkaListener的ackMode配置），减少Broker的负担。

• 开启详细日志排查隐性问题
  默认日志级别可能会忽略Kafka客户端和Spring Kafka容器的关键调试信息。建议临时开启org.apache.kafka和org.springframework.kafka的DEBUG级别日志，在故障发生时查看：

  • 是否有心跳超时、fetch请求失败、offset提交失败的日志；
  • 是否有消费者组重平衡的记录；
  • 是否有ZooKeeper连接异常的信息。
    这些日志能帮你定位到是网络问题、Broker问题还是客户端本身的异常。

• 检查企业级Kafka集群的配额与限流策略
  企业级Kafka集群通常会配置消费者的配额限制（比如每秒拉取的消息量、请求次数），如果你的消费者触发了这些配额，Broker会限制其拉取能力，甚至静默拒绝请求，导致消费者看起来“停止消费”。可以联系集群管理员：

  • 查看消费者所在组的配额使用情况；
  • 检查Broker是否有针对该消费者IP的限流规则；
  • 确认Broker近期是否有GC停顿、网络分区或节点故障的情况。

• 排查消费者线程的状态
  在故障发生时，使用jstack命令导出应用的线程栈，查看Kafka相关的线程（名称通常包含kafka-consumer或spring-kafka）的状态：

  • 如果线程处于WAITING或TIMED_WAITING状态，可能是在等待ZooKeeper或Broker的响应，说明网络或集群有延迟；
  • 如果线程处于BLOCKED状态，可能是应用代码中的锁竞争导致消费线程无法继续执行。

• 验证消息本身是否存在异常
  虽然你提到消息只有几KB，但偶尔出现的超大消息（超过fetch.max.bytes或max.partition.fetch.bytes配置）可能导致消费者卡住。可以在故障期间检查主题中的消息：

  • 使用kafka-console-consumer.sh手动消费主题，看是否能正常拉取消息；
  • 检查是否有消息大小超出消费者配置的限制。

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