晚高峰送礼消息堆了50万条，Doris大盘延迟5分钟——消费积压怎么办？
先说结论
消费积压只有两个原因：生产太快或消费太慢。排查思路：先看Lag确认积压量和趋势 → 再分方向定位原因 → 对症下药。90%的积压是消费端跟不上导致的。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
消费积压（Consumer Lag）是Kafka生产环境最常见的报警之一。在某元宇宙社交公司做实时数仓那会儿，每到晚上8-10点直播间送礼高峰，gift_txn的Topic就开始堆消息，Doris上的实时大盘延迟飙到分钟级。后来在某短剧出海公司，投放数据要求5分钟时效，Kafka积压直接影响投手做决策。这道题面试官想看的是你有没有系统性的排查思路，而不是上来就说'加机器'。
第一步：看指标，搞清楚三个问题
不要一上来就调参数。先搞清楚：① 积了多少条；② 在涨还是在降；③ 是哪个Partition积压。
# 用kafka-consumer-groups命令查看（最常用）
kafka-consumer-groups.sh --bootstrap-server broker1:9092 \
--describe --group flink-realtime-dashboard
# 输出示例（我实际遇到的情况）：
# TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG
# gift_txn 0 800000 820000 20000
# gift_txn 1 790000 810000 20000
# gift_txn 2 760000 880000 120000 ← 严重！
# gift_txn 3 800000 815000 15000
#
# Partition-2 Lag特别大 → 可能是数据倾斜或该Consumer有问题
# 所有Partition都在涨 → 整体消费速度跟不上我当时用Know Streaming的Web界面看Lag趋势图更直观——Lag平稳说明有固定延迟但追得上；Lag持续增长说明消费速度 < 生产速度。
第二步：定位原因
| 方向 | 排查方法 | 典型现象 |
|---|---|---|
| 生产端突增 | 看Producer发送速率、上游业务突发 | 所有Partition Lag同步增长 |
| 消费端太慢 | 看Flink反压、下游写入延迟、GC | 个别Partition Lag特别大 |
| Rebalance | 看Consumer Group日志 | Lag突然跳涨后慢慢恢复 |
| 数据倾斜 | 某Partition Lag远大于其他 | 单Partition积压严重 |
解法一：优化消费端（最常用）
① 增加Consumer实例（水平扩容）
对Flink来说就是增加并行度。但并行度不能超过Partition数——6个Partition配12个并行度，有6个空闲。先增Partition再加并行度。
② 优化下游写入（这才是根因！）
很多时候Kafka消费慢不是Kafka的问题，是下游写入慢。我的经历就是典型：
// 优化前：Flink逐条写Doris（慢）
// 每消费一条消息就INSERT INTO一次
// Doris每次INSERT都做mini-compaction，吞吐量极低
// 优化后：Flink攒批 + Doris Stream Load（快5倍）
// Flink用ProcessFunction攒够1000条或等5秒
// 然后用Doris Stream Load API批量写入
//
// 效果：写入吞吐从200条/秒提升到5000条/秒
// Kafka Lag从10万+降到几百条
// Metabase上的实时大盘延迟从分钟级降到秒级③ 调整Flink消费配置
// Flink的Kafka Source配置优化
properties.setProperty("fetch.min.bytes", "1048576"); // 1MB减少fetch次数
properties.setProperty("fetch.max.wait.ms", "500"); // 等500ms攒够再返回
properties.setProperty("max.poll.records", "1000"); // 每次多拉一些
// 注意：max.poll.records要和max.poll.interval.ms配合
// 拉多了处理不完就会触发Rebalance（上一篇讲的坑）解法二：临时应急方案
如果积压太多短时间消费不完，且业务能接受跳过历史数据：
# 方案一：重置offset到最新（慎用！丢弃积压数据）
kafka-consumer-groups.sh --bootstrap-server broker1:9092 \
--group flink-realtime-dashboard \
--topic gift_txn \
--reset-offsets --to-latest --execute
# 方案二：按时间重置（保留最近1小时数据）
kafka-consumer-groups.sh --bootstrap-server broker1:9092 \
--group flink-realtime-dashboard \
--topic gift_txn \
--reset-offsets --to-datetime 2023-01-15T21:00:00.000 --execute
# 方案三：临时Consumer转储到S3，后续离线补数据
# 我用过这个方案——实时链路先跳过，离线T+1批处理补回来实战踩坑：晚高峰积压排查全过程
有一次周五晚高峰，gift_txn的Lag从平时几百条飙到50万条。我的排查步骤：
① 看Lag分布：6个Partition都在涨，不是倾斜，是整体消费太慢。
② 看Flink Task：Flink Web UI显示Sink算子（写Doris）反压100%，Source算子（读Kafka）完全空闲。瓶颈在Doris写入。
③ 看Doris：BE节点CPU飙到90%，正在做大量compaction。写入延迟从几ms涨到秒级。
④ 应急处理：等compaction完成后，暂停Flink Job，重置offset到30分钟前，重启。Lag在10分钟内降到正常。
⑤ 长期优化：Doris写入从逐条INSERT改成批量Stream Load；设compaction策略避免高峰期触发；用Metabase展示Lag趋势接报警。整体数据查询延迟也提升了70%。
面试高频追问
追问一：Partition数=Consumer数了还能怎么提速？
三个方向：① 增Partition+Consumer（有副作用）；② 优化单Consumer处理逻辑（异步写、批量写）；③ 消费内部多线程（注意offset提交顺序）。通常优化下游写入效果最好。
追问二：怎么设置积压报警？
两级阈值：Warning（Lag>1万持续5分钟）和Critical（Lag>10万或持续增长30分钟）。我用Know Streaming配Lag监控接即时通讯报警；在短剧公司用云平台自带的监控。
总结
消费积压排查三板斧：① 看Lag分布（全局慢还是单Partition倾斜）；② 定位瓶颈（大概率是下游写入慢）；③ 对症下药（优化下游写入 > 扩容Consumer > 应急跳过）。面试能讲出完整排查过程：看指标→定位瓶颈→解决→事后优化，这道题就稳了。
下一篇聊Kafka的存储核心：消息在磁盘上怎么存的？为什么顺序写磁盘能这么快？
你们遇到过最严重的消费积压有多少条？怎么解决的？评论区聊聊～
关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长