考察点
这是一道实战运维题，面试官想看你有没有处理过线上积压。合格答案要有清晰的排查顺序：先量化（lag 多少、是涨是稳），再定位（哪类瓶颈），最后分级处置（止血 vs 根治）。只会说"加消费者"的过不了追问——分区数不够怎么办、下游库扛不住怎么办、能丢吗？
参考答案
先量化：lag 是什么，怎么看
积压的度量是 consumer lag：分区最新位移（LEO）减去消费者已提交的位移。kafka-consumer-groups.sh --describe 能看，线上一般是接 Burrow 或 Prometheus 的 kafka_exporter 做监控。看 lag 要同时看两个维度：绝对量（积压了多少条，换算成时间——按消费速率算追平要多久）和趋势（lag 是持续上涨、稳定不动还是周期性波动）。
趋势比绝对量更说明问题：持续上涨说明消费速率 < 生产速率，长期必然爆炸；稳定一个大值不动，可能是消费者卡住但生产也慢；周期性尖峰可能是上游批量任务导致，未必需要处理。
排查的四类根因
1. 消费逻辑本身慢。 最常见。单条消息处理耗时乘以 QPS 超过了消费能力。看消费者机器 CPU/IO，看处理链路里的外部调用（数据库、RPC）耗时。验证方法：把处理逻辑临时换成空跑（只拉不处理），如果 lag 飞速下降，瓶颈就在业务处理。
2. 分区分配不均或并行度不够。 实例数 ≥ 分区数时加机器没用；key 倾斜时个别分区积压严重而其他分区很闲。看每个分区的 lag 分布，别只看总数。
3. Rebalance 频繁。 消费反复停摆，lag 呈锯齿状上涨。查 Rebalance 日志，多半是处理超时（max.poll.interval）或 GC 导致心跳超时。这种情况加资源没用，先解决稳定性。
4. 下游是瓶颈。 消费者把数据写 MySQL、ES、HBase，下游限流或变慢，反压到消费端。lag 只是症状，病根在下游。看下游写入耗时和错误率。
分级处置：先止血再根治
临时止血（小时级）：
- 消费者实例数 < 分区数：直接加实例，立竿见影。
- 实例数已到分区数上限：临时建一个新的、分区数更多的主题，写一个转发程序把老主题的消息灌进新主题，用更多消费者并行消费新主题追平积压。这是"分区数不够"场景的标准应急方案，追平后再切回原主题（下游幂等要能兜住这段切换）。
- 下游是瓶颈：消费端限流降级，先保下游别被打死，再扩下游。
消息能不能丢要想清楚： 日志类数据可以接受直接 seek 到最新位移跳过积压（seekToEnd 或重置 group offset）；交易类绝对不行。这是业务决策，不是技术决策，面试官会看你是否意识到要问这一句。
根治（天级）：
- 处理逻辑优化：批量处理（攒一批再写库，别逐条 insert）、异步化非关键路径、去掉处理链路里的同步 RPC。
- 分区数评估：长期看分区数要按峰值吞吐重新规划，注意加分区影响 key 路由。
- 下游扩容或换方案：MySQL 顶不住批量写，考虑换 OLAP 引擎或先落宽表。
- 监控前移：lag 告警阈值按"追平时间"设（比如 lag 持续上涨超过 30 分钟就告警），别等堆积几小时才发现。
一个容易忽略的点：磁盘空间
积压不只是消费问题，还牵动 Broker 存储。retention 按时间（默认 7 天）或大小清理，积压期间数据量暴涨可能打满磁盘。排查积压时顺手看一眼 Broker 磁盘水位，必要时临时调大 retention.ms——数据被清理了，消费者 seek 过去的位移不存在了，那才是真丢数据。
可能的追问
- 消费者加了一倍的实例，lag 降得却不明显，为什么？ 先看是不是实例数已超分区数（多的在空转）；再看瓶颈是否在外部依赖（数据库/下游），那种情况加消费者反而把下游压得更慢。
- 怎么避免积压时的重复消费淹没下游？ 追积压期间 Consumer 崩溃重启会从旧位移重拉，下游幂等必须做好；转发方案里新旧主题切换也要靠幂等保证不重不漏。
- lag 监控用 committed offset 有什么盲区？ 自动提交或提交间隔大时，committed offset 滞后于实际消费进度，lag 虚高；反之消费者卡住不提交时 lag 看起来不动。结合消费者心跳和处理耗时指标一起看才准。