1. 并发与分区监听并发KafkaListener(concurrencyN)/factorysetConcurrency一个 listener 起 N 个消费线程分区数Topic partition 数有效并发 ≤ 分区数线程多于分区会闲着拆 listener分开订阅监听互不抢分区、互不影响 lag2. 单次 poll 捞多少max.poll.recordstopic每秒生成多少核有多少节点在一起消费判断 200单批更多吞吐↑、单批处理时间↑延迟↓、更实时fetch.min.bytes默认 1等凑够再返回 → batch 更大有数据立刻返回 → 常出现 batchSize1fetch.max.wait.ms默认 500配合 min.bytes 多等一会攒批更低延迟fetch.max.bytes/max.partition.fetch.bytes默认较大单次拉取体积上限防单批过大打爆内存3. 确认与投递方式AckMode.MANUAL_IMMEDIATE你们现状每条处理完立刻 ack安全性好改 BATCH ack整批处理完再提交减少提交次数4. 业务侧「变相调优」心跳提前过滤少打日志、少进业务等同提高有效吞吐。重逻辑异步化listener 只做校验/落轻量数据重活丢线程池/队列避免拖长 poll 间隔。消费线程是否真在干活线程 dump / 日志 thread 名GC 停顿是否拉长costMs、触发 rebalanceDB/下游连接池是否成为瓶颈CPU 空闲但 lag 涨 → 多半是下游查看服务器上应用cpu占用是不是jvm没有性能拉起来调整JVM参数给到服务器50%-70%线程数 调好后瓶颈常从 CPU 转到下游 IO这时加 concurrency 收益有限应优化业务或改批量