Kafka 3.2.1升级后批量监听器部分分区停止消费问题排查求助

兼容性阻塞点确认 #

Spring Boot 2.7.x/2.8.x对应的Spring Kafka版本为2.8.x，根据官方兼容性矩阵，Spring Kafka 2.8.x官方支持的Kafka Broker版本范围是2.8.0~3.2.0，3.2.1作为3.2.x的小版本更新，存在部分未被Spring Kafka 2.8.x适配的协议细节，主要阻塞点集中在：

• Cooperative Sticky分配器重平衡逻辑：Kafka 3.2.1对cooperative模式下的分区revoke/assign流程做了细微调整，但Spring Kafka 2.8.x的MessageListenerContainer未适配该调整，导致重平衡后部分分区的拉取线程无法被正确唤醒
• 批量监听器Offset提交冲突：Kafka 3.2.1消费者客户端的批量Offset提交校验逻辑更严格，Spring Kafka 2.8.x的批量监听器提交逻辑在重平衡后可能出现元数据不一致，引发提交失败但未触发重试

具体排查建议 #

1. 验证分区分配与Offset状态 #

• 执行Kafka命令行工具确认消费组状态：

  kafka-consumer-groups.sh --bootstrap-server <broker地址> --describe --group <消费组ID>
  

  重点查看未消费分区的CURRENT-OFFSET、LOG-END-OFFSET以及OWNER字段，确认分区已分配给目标Pod且Offset未停滞在旧值
• 开启org.springframework.kafka.listener.ConsumerRebalanceListener的DEBUG日志，确认重平衡时分区的revoke和assign动作是否完整，无遗漏

2. 调整批量监听器配置与提交策略 #

• 临时修改ackMode为RECORD（原配置可能为BATCH或MANUAL），验证是否能恢复消费，以此确认是否为批量提交逻辑导致的阻塞
• 开启Offset提交调试日志：打开org.apache.kafka.clients.consumer.internals.ConsumerCoordinator和org.springframework.kafka.support.LoggingProducerListener的DEBUG日志，排查是否存在Offset提交失败、超时的情况

3. 隔离Cooperative Sticky分配器问题 #

• 临时切换分配策略为RangeAssignor，修改配置：

  spring.kafka.consumer.partition-assignment-strategy=org.apache.kafka.clients.consumer.RangeAssignor
  

  重新触发重平衡，若问题消失，则可确认是Cooperative Sticky分配器与Kafka 3.2.1的适配问题
• 检查是否存在分配策略冲突：确保未同时配置多种分配策略，避免逻辑混乱

4. 排查Kubernetes环境层面问题 #

• 检查Pod的资源使用情况：查看CPU throttling、内存OOM日志，确认拉取线程未因资源限制被挂起
• 验证网络连通性：重平衡后，检查Pod与未消费分区对应的Broker节点的网络是否通畅，可通过telnet或nc命令测试端口连通性

5. 版本适配升级 #

• 若无法升级Spring Boot版本，可单独升级Spring Kafka到2.8.11+（Spring Boot 2.7.x兼容该补丁版本），该版本修复了部分与Kafka 3.2.x的兼容性问题
• 若允许升级，可将Spring Boot升级到3.0.x+（对应Spring Kafka 2.9.x），官方完全支持Kafka 3.2.1

内容的提问来源于stack exchange，提问作者François Rosière