场景凌晨 3 点监控系统报警发现某个核心 Topic 的消息积压了上千万条且消费速度远远跟不上生产速度。作为值班工程师你该如何快速恢复业务减少积压紧急处理四步走SOP第一步紧急止血切断源头如果积压是由上游非核心业务流量突增如爬虫、营销活动引起的立即联系上游暂停生产者或者在网关层进行限流/降级。如果是消费者代码刚发布导致的故障如死循环、空指针立即回滚到上一个稳定版本。第二步常规扩容提升消费能力增加消费者实例这是最快见效的手段。如果 Topic 有 10 个分区当前只有 2 个消费者立即将消费者扩容到 10 个注意消费者数量不能超过分区数否则多余的会闲置。优化消费参数临时调整消费者配置例如增大 max.poll.records单次拉取条数减少网络交互次数或者调大 fetch.max.bytes。第三步非常规手段临时 Topic 转发法如果原 Topic 的分区数已经限制了并发度例如只有 3 个分区或者消费逻辑太重无法快速优化可以采用“消息转发”策略。操作编写一个临时的“转发消费者”只负责从原 Topic 快速拉取消息不做任何业务处理直接转发到一个新建的、拥有海量分区如 50-100 个的临时 Topic 中。消费部署大量的临时消费者如 50-100 个去消费这个临时 Topic快速消化积压数据。第四步丢弃或降级极端情况如果积压数据是非核心日志且过期无效可以直接修改消费者逻辑跳过处理直接提交 Offset。或者将消息转存到死信队列或 HDFS 中待高峰期过后再进行离线补偿处理。追问临时扩容消费者有用吗如果原来的消费者逻辑很重比如处理一条要 1 秒在扩容时你会采用什么架构来快速消化积压例如临时转发 Topic 方案1.临时扩容消费者有用吗有用但有上限。限制条件Kafka 的并行度取决于分区数Partition Count。如果你的 Topic 只有 3 个分区那么你启动 100 个消费者也是没用的只有 3 个消费者能工作其余 97 个都会处于空闲状态。结论扩容消费者的前提是分区数 当前消费者数。如果分区数不足必须先扩容分区kafka-topics.sh --alter但这会触发重平衡且对历史数据无效。2.针对“重逻辑”的积压处理架构临时 Topic 转发方案当原消费者逻辑太重例如涉及复杂的数据库关联查询、第三方 API 调用处理一条需 1 秒单纯增加消费者数量受限于分区数且单条处理慢的问题没解决。此时“临时 Topic 转发方案”是最佳架构架构设计新建 Topic创建一个新 Topic例如 order-topic-temp设置极大的分区数例如 100 个分区以支持极高的并行度。部署转发程序写一个简单的程序或者复用原消费者组它的逻辑极其简单拉取消息 - 转发到新 Topic。因为它不处理业务速度极快能迅速把原 Topic 的积压“搬运”走。部署海量消费者针对 order-topic-temp部署 100 个消费者实例。业务分流这 100 个消费者执行原本“重逻辑”的业务。由于分区多、实例多整体吞吐量会成倍提升。为什么这样有效解耦将“搬运数据”和“处理业务”解耦。并行度最大化通过新建高分区数的 Topic打破了原 Topic 分区数对并发度的限制。隔离避免了原 Topic 的重平衡对实时新消息的影响可以配置转发程序只消费积压的旧数据或者新数据直接发往新 Topic。注意事项这种方案可能会导致消息顺序性丢失因为新 Topic 分区策略可能不同适用于对顺序要求不苛刻或者可以在业务层做最终一致性补偿的场景。积压清理完毕后记得下线临时 Topic 和转发程序。