场景：凌晨 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 和转发程序。
