消息积压处理

用途：堆积量持续上涨时快速止血并根治

先判断性质

类型	特征	处理方向
生产突增	上游发布/活动/重试风暴导致量级上涨	扩容 + 上游限流
消费变慢	单条耗时上升（下游 RT、GC、锁）	修性能瓶颈
消费失败	大量重试，成功率低	修异常，隔离毒消息
消费者掉线	实例数减少、再均衡卡住	恢复实例，检查订阅一致性
队列倾斜	部分队列堆积，其余正常	调整 key 分布/队列数

应急手段（按见效速度）

1. 提高并行度：加消费者实例（前提：队列数足够）+ 提升每实例线程数。
2. 临时旁路：新建一个“扩容消费者组”，把消息快速搬运到队列数更多的中转 Topic，再由多实例消费（经典做法，需注意最终仍要回到原组语义）。
3. 降级非核心逻辑：跳过通知、统计、埋点等旁支处理，只保核心落库。
4. 批量消费 + 批量写：把逐条写 DB 改为攒批写，吞吐常能提升数倍。
5. 暂停上游：配合业务侧限流或开关，避免继续恶化（需要业务确认可接受）。
6. 绝对不要：直接跳过消息（丢数据）、或把重试次数调大“等它自己好”。

根治清单

• 消费能力压测：给出单实例 TPS 上限与队列数规划，避免“上线即积压”。
• 幂等 + 攒批：让消费可以安全重放并具备批量能力。
• 慢消费告警：单条耗时 P99、重试率、堆积增速三条告警。
• 毒消息隔离：格式错误/业务拒绝类消息直接进隔离队列，不阻塞主流程。
• 容量弹性：消费者组支持按堆积量自动扩缩（KEDA 类机制）。
• 上游治理：批量任务发送要限速，避免瞬时百万条灌入。

关键指标

堆积量 = 最大位点 − 消费位点（按队列求和）
消化速率 = 消费 TPS − 生产 TPS
预计恢复时间 = 堆积量 / 消化速率

只有“预计恢复时间”能回答老板的问题：“还要多久追平”。

常见误区

误区	修正
只加机器不加队列	并行度受队列数限制
以为积压只是延迟	超过消息保留期会变成丢数据
消费端 catch 异常返回成功来“清积压”	数据静默丢失，事故升级
盲目调大拉取批量	单批处理时间变长，重试代价更大
事后不补容量模型	下次活动仍会积压

延伸阅读

• Apache RocketMQ 官方文档：消息堆积与运维建议
• Martin Kleppmann《数据密集型应用系统设计》第 4 章（背压与批量）