线上 kafka 消息堆积，consumer 掉线，怎么办？

最新推荐文章于 2025-05-18 17:18:08 发布

原创

最新推荐文章于 2025-05-18 17:18:08 发布 · 956 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#kafka #java #大数据

本文记录了一次线上Kafka消息堆积和消费者掉线的故障排查过程。通过Arthas调整日志级别，发现由于消费时间过长，导致客户端自我驱逐。最终定位为业务代码中的死循环造成消费阻塞，从而引发问题。文章还探讨了Kafka客户端超时处理机制，并提出了Kafka使用最佳实践，包括异常情况处理、消费速度优化、参数调整等建议。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

线上 kafka 消息堆积，所有 consumer 全部掉线，到底怎么回事？

最近处理了一次线上故障，具体故障表现就是 kafka 某个 topic 消息堆积，这个 topic 的相关 consumer 全部掉线。

整体排查过程和事后的复盘都很有意思，并且结合本次故障，对 kafka 使用的最佳实践有了更深刻的理解。

好了，一起来回顾下这次线上故障吧，最佳实践总结放在最后，千万不要错过。

1、现象

线上 kafka 消息突然开始堆积
消费者应用反馈没有收到消息（没有处理消息的日志）
kafka 的 consumer group 上看没有消费者注册
消费者应用和 kafka 集群最近一周内没有代码、配置相关变更

2、排查过程

服务端、客户端都没有特别的异常日志，kafka 其他 topic 的生产和消费都是正常，所以基本可以判断是客户端消费存在问题。

所以我们重点放在客户端排查上。

1）arthas 在线修改日志等级，输出 debug

由于客户端并没有明显异常日志，因此只能通过 arthas 修改应用日志等级，来寻找线索。

果然有比较重要的发现：

2022-10-25 17:36:17,774 DEBUG [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] - [Consumer clientId=consumer-1, groupId=xxxx] Disabling heartbeat thread 2022-10-25 17:36:17,773 DEBUG [org.apache.kafka.clients.consumer.internals.AbstractCoordinator] - [Consumer clientId=consumer-1, group