破题（指出限制）：“RocketMQ 的队列模型决定了消费者数量不能超过 Queue 的数量。单纯加机器无效。”
避坑（原 Topic 扩容无效）：“即使直接修改原 Topic 的 Queue 配置，也无法解决存量积压，因为旧消息依然存储在旧队列中，无法并行消费。”
解决方案（转发+扩容）：“我的方案是‘流量分流 + 临时扩容’：上线一组不带业务逻辑的‘搬运 Consumer’，只负责把积压消息转发到一个 Queue 数量为 100 的临时 Topic 中。然后上线 100 个真实的业务 Consumer 去消费那个临时 Topic。 ”
兜底（高阶思维）：“但在执行前，我会确认三点：
1）消息是否要求严格顺序？
2）MQ 集群的 I/O 是否有余量？
3）下游 MySQL 能否抗住 100 个并发的洪峰？如果是非核心数据，我会建议直接丢弃或跳过积压，优先保证服务恢复。”