消息积压处理方案#

紧急处理：

1. 扩容消费者实例(Kafka需先扩Partition)
2. 临时调大消费线程数
3. 跳过/转存非核心消息
4. 新建临时Topic分流

根治： 优化消费逻辑(批量处理/异步化) / 合理设置Partition数

消息积压本质是消费速度跟不上生产速度，处理分紧急和根治两个层面。紧急处理首先是扩容消费者实例来提高消费并行度，但 Kafka 要注意消费者数不能超过 Partition 数，所以需要先扩 Partition 再扩消费者；其次可以临时调大单个消费者的消费线程数；对于非核心消息可以先跳过或转存到其他 Topic 后续慢慢处理，优先保证核心业务消息的消费；还可以新建临时 Topic 把积压消息分流到更多消费者处理。根治层面要从消费逻辑本身入手：优化消费处理逻辑减少单条消息的处理时间，比如批量处理替代逐条处理、异步化 IO 操作、减少不必要的远程调用；合理设置 Partition 数量让消费者能充分并行。另外还要建立监控告警机制，对消费延迟设置阈值，积压达到一定量就自动告警，避免问题积累到不可控才发现。

追问方向：

• “消息积压的常见原因有哪些？”→ 消费者处理慢（下游服务超时/GC/慢 SQL）、消费者实例数不足或挂了、生产端突发流量、Rebalance 频繁导致消费停顿
• “积压了几百万消息怎么紧急处理？”→ 临时扩容：新建一个多分区的临时 Topic，写一个只做转发的消费者把积压消息分发到新 Topic，然后用大量消费者并行消费临时 Topic 快速消化
• “怎么预防消息积压？”→ 提前做容量规划（分区数≥消费者数）、消费端异步化批量处理、设置消费延迟监控告警（如 Kafka lag 监控）、消费者做好限流降级避免雪崩

易错点：

• ❌ 只知道概念不知道原理——面试官会追问底层实现
• ❌ 缺乏实际使用经验——结合项目场景回答更有说服力