消息积压（堆积）了怎么处理？

简化版

消息积压指生产速度远大于消费速度，导致消息在 MQ 里越堆越多。处理分两步：① 先止血/定位——查清是消费者出故障（挂了/卡住/报错）还是消费能力不足（流量突增），故障就先修复消费者；② 提升消费速度——最直接是加消费者实例，但受限于「分区数」（消费者数不能超过分区数），如果分区不够，可以临时加一个中转消费者：它只负责快速把积压消息转发到一个分区更多的新 Topic，再由更多消费者并行消费。事后要复盘根因、扩容、加监控告警。

详细版

积压的常见原因：

消费者故障：消费者宕机、卡死、或消费逻辑一直报错重试，导致消费停滞。
消费能力不足：流量突增（大促）超过消费者处理能力；或消费逻辑变慢（如依赖的下游变慢、慢查询）。
消费者太少 / 分区太少：并行度不够。

处理步骤：

定位原因：看监控——是消费者挂了/报错（故障类），还是消费速率跟不上生产速率（能力类）。
故障类：先修复消费者（重启、修 bug、恢复依赖），消费恢复后积压会逐渐消化。
能力类，加消费者：增加消费者实例来提升并行消费能力。但有上限：一个分区只能被一个消费者消费，所以消费者数量 ≤ 分区数，加到等于分区数就到顶了。
分区不够的应急方案：临时写一个「中转消费者」，它不做业务处理，只快速把积压消息原样转发到一个分区数更多的新 Topic，再用大量消费者并行消费新 Topic。相当于临时扩大并行度。
事后：复盘根因、永久扩容分区和消费者、加积压监控告警。

完整版教学

一、第一件事：定位，别盲目扩容

看到积压先别急着加机器，要先判断是「故障」还是「能力不足」，因为解法完全不同：

如果是消费者故障（消费者挂了、消费逻辑抛异常一直重试、依赖的数据库/下游挂了导致处理卡住），此时加再多消费者也没用——它们同样会卡住。应该先修复故障（重启消费者、修 bug、恢复下游依赖），消费一旦恢复，积压的消息会被逐步消化掉。
如果是能力不足（消费者都正常，只是生产速度突然超过消费速度，如大促流量），才需要提升消费能力（加消费者/加分区）。

盲目扩容而不定位根因，可能白忙一场（故障没修，加了机器还是卡）。所以第一步永远是看监控、定位原因。

二、提升消费速度的正道：加消费者（受分区数限制）

确认是能力不足后，最直接的提速办法是增加消费者实例，多个消费者并行消费不同分区。但这里有个硬约束：一个分区在同一时刻只能被同一消费组里的一个消费者消费。所以：

消费者数量 ≤ 分区数才有意义。分区有 8 个，消费者加到 8 个就到顶了，再加的消费者会空闲（分不到分区）。
如果分区数本身就不够（比如只有 4 个分区，但需要更高并行度），加消费者也突破不了 4 的并行度。

所以「加消费者」的天花板是「分区数」。这也提醒我们：分区数在设计时要留有余量，否则积压时想扩并行度都扩不了（在线增加分区对顺序性等有影响，不能随意加）。

记忆点：处理积压先定位（故障还是能力不足）——故障先修消费者，能力不足才扩容。扩容加消费者受「消费者数 ≤ 分区数」限制；分区不够时用「中转消费者转发到多分区新 Topic」应急扩大并行度。

三、分区不够时的经典应急方案

如果积压严重、又需要远超现有分区数的并行度来快速消化，有一个经典的应急手段——临时加一层中转：

新建一个分区数很多（如 40 个）的临时 Topic。
写一个中转消费者，它消费原来积压的 Topic，但不做任何业务处理，只把消息原样快速转发到新的 40 分区 Topic。因为它不处理业务、只做转发，速度极快，能顶住。
部署大量消费者（如 40 个）去并行消费新 Topic，做真正的业务处理。

这样把并行度从原来的 N 临时放大到 40，快速消化积压。积压清完后，再恢复正常架构。这是应对突发严重积压的标准套路。

四、其他提速手段

除了加并行度，还可以从「单个消费者处理更快」入手：

批量消费：一次拉取一批消息批量处理（如批量写数据库），减少单条处理的开销。
优化消费逻辑：把慢的部分（如同步调用下游、慢 SQL）优化或异步化，提升单条处理速度。
临时降级：积压期间，把消费逻辑里非核心的步骤暂时关掉，只做核心处理，加快速度，事后再补。

五、事后：根治与预防

应急消化完积压后，要做长效治理：

复盘根因：为什么积压？流量评估不足？消费者性能瓶颈？依赖故障？
永久扩容：增加分区数和消费者数，留足余量。
加监控告警：对「消息积压量 / 消费延迟」设置告警，积压刚冒头就发现，而不是等堆成灾。
压测：提前压测消费能力，确保能扛住预期峰值。

六、常见误区与追问

这道题不能只背概念，要把「消息积压」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。

回答层次	要讲清的内容	容易漏掉的边界
核心结论	消息积压是生产速度长期大于消费速度或消费者故障，导致队列堆积和延迟上升	不要停在名词解释
流程机制	监控 lag 和消费耗时 -> 定位生产突增或消费变慢 -> 扩容消费者或分区 -> 优化单条处理耗时 -> 限流生产者 -> 处理死信和失败重试	说明触发方、存储方、确认点和兜底
工程取舍	生产 10 万条/分钟，消费只能 3 万条/分钟，每分钟会新增 7 万条积压	MQ 解耦削峰但带来最终一致、重复消费和可观测性要求

消息积压 面试拆解：
1. 监控 lag 和消费耗时
2. 定位生产突增或消费变慢
3. 扩容消费者或分区
4. 优化单条处理耗时
5. 限流生产者
6. 处理死信和失败重试

记忆钩子：先拆生产者、Broker、消费者、offset、重试和幂等，再说明丢失、重复、顺序和积压边界；回答时要紧扣「消息积压」这道题，不要把相邻概念混成一段泛泛的分布式套话。

误区：积压只要加消费者就行。 若分区数不足、下游慢或单条处理慢，加消费者未必有效。
误区：积压不会影响业务。 延迟会让订单状态、通知、库存同步等最终一致窗口变长。
误区：重试越快越好。 失败重试过快会占用消费能力，加剧积压。
追问：先看哪些指标？ lag、TPS、消费耗时、失败率、重试数、分区分布和下游延迟。
追问：如何快速止血？ 临时扩容、跳过非核心任务、限流生产、批量消费和降级。
追问：如何长期治理？ 容量评估、分区规划、慢消费优化和死信处理流程。

七、加强记忆

消息积压 = 生产速度 > 消费速度。处理两步：① 先定位——故障（消费者挂/报错/依赖卡住）还是能力不足（流量突增），故障就先修消费者（加机器没用），能力不足才扩容。② 提速——加消费者，但受「消费者数 ≤ 分区数」限制；分区不够时用经典应急方案：中转消费者不做业务、只把积压消息快速转发到分区更多的新 Topic，再用大量消费者并行消费。辅以批量消费、优化逻辑、临时降级。事后复盘根因、永久扩容分区和消费者、加积压监控告警。

简化版

详细版