一、先止血防止继续堆限流或降级生产端网关/业务对产生消息的接口限流非核心异步任务日志、埋点、统计先降级或关掉临时扩容消费者快速多开几份同样的消费服务实例适当调大每个实例的消费线程数注意别把 DB/下游打挂一句话先控制入口 暂时多拉人干活。二、再疏通提高“单条消息处理效率”检查是否有异常重试导致“假堆积”一直消费失败 → 死循环重试 → 队列看起来很多处理失败消息快速丢到 死信队列 / 重试队列主队列只放正常消息设置最大重试次数和间隔优化消费逻辑去掉不必要的远程调用/慢 SQL能缓存的缓存尽量改为批量处理一次拉 N 条一起写 DB / 一次调一次批量接口给 DB 加合适索引避免消费端自己搞出慢 SQL分流不同优先级/业务类型拆 topic 或 拆 tag核心业务一个队列非核心一个队列不要让非核心阻塞核心比如埋点、通知阻塞下单流三、再扩容结构级解决而不是只堆机器增加分区/队列数Kafka 分区、RocketMQ queue 数量一个分区同一时刻只能被一个消费者线程消费想水平扩就要有更多分区 → 更多并行度消费者集群水平扩容按分区数增加消费实例合理配置消费组注意不要超过下游DB、第三方的承载能力四、最后防止再次堆积预防方案容量规划与报警监控指标消息堆积数、堆积时长、消费速率、生产速率提前告警比如堆积条数 N或“生产速率持续大于消费速率 M 分钟”报警限流 降级策略常态化核心链路下单、支付优先保证非核心可随时关幂等与重试设计好消费端支持幂等这样临时加线程/实例、批量重放消息时不怕重复