先看消费者组 lag 和分区分配情况，再结合消费逻辑耗时与配置参数判断是否真慢、慢在哪一环：用 kafka-consumer-groups.sh 查 lag 定位堆积分区，kafka-topics.sh 核查 leader 均衡，perf-test 测真实吞吐，检查 max.poll.records、同步阻塞、offset 提交及 rebalance 原因。

直接看消费者组 lag 和分区分配情况，再结合消费逻辑耗时与配置参数判断是否真慢、慢在哪一环。

查 lag 和分区分配状态

用标准命令快速确认堆积位置和范围：

• kafka-consumer-groups.sh --bootstrap-server <broker> --group <group-name> --describe：重点看 LAG 列，确认哪些分区 lag 高、是否集中在少数几个分区
• 若高 lag 分区都由同一台消费者机器处理，先检查该机器 CPU、内存、磁盘 IO 是否打满；若重启后 lag 分区被重新分配但依然堆积，大概率不是客户端单点故障
• 运行 kafka-topics.sh --describe --topic <topic>，核对高 lag 分区的 Leader 副本是否落在负载偏高的 broker 上（比如优先副本是 3，实际 Leader 是 2），这种非均衡会导致消费瓶颈

测真实消费吞吐能力

排除监控偏差，用压测工具验证当前消费端极限：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 执行 kafka-consumer-perf-test.sh，指定相同 group 和 topic，跑固定消息量（如 10 万条），观察实际每秒消费条数和平均延迟
• 对比生产端吞吐：kafka-producer-perf-test.sh 测出的 TPS，若消费 TPS 明显低于生产 TPS，且无报错日志，基本锁定为能力不足
• 注意测试时关闭业务逻辑（比如注释掉写库、调 MES 接口等），只保留 Kafka 拉取+提交 offset，可判断是纯框架瓶颈还是业务逻辑拖慢

看消费逻辑与关键参数

很多“慢”其实卡在代码或配置细节上：

• 检查 max.poll.records 是否设得过大（如 5000），导致单次拉取太多消息，处理时间超过 max.poll.interval.ms，触发 rebalance 后反复暂停消费
• 确认业务代码里是否有同步阻塞调用（如未设超时的 HTTP 请求、数据库长事务），哪怕一条消息卡住，整个分区就停摆
• 查看是否启用了手动提交 offset 但忘记提交，或提交失败后没重试，导致 offset 不推进，监控显示 lag 却实际没消费

观察重平衡与心跳行为

频繁 rebalance 表面是“慢”，实则是稳定性问题：

• 日志中搜索 RebalanceInProgressException 或 Heartbeat failed，确认是否因 session.timeout.ms 过短或处理超时引发反复重分配
• 若消费者数量 > 分区数，多余实例长期空闲，不仅不提速还增加协调开销；应确保 consumer 实例数 ≤ 分区数，且尽量接近
• 检查消费者启动后是否真正加入 group——kafka-consumer-groups.sh --list 能看到 group，但 describe 里没有 consumer-id 和 host，说明根本没成功注册