那天下午，库存服务一次 fullGC 把消费者线程全停了。GC 持续了 28 分钟，消费者一直没心跳，RocketMQ 以为它还活着就没触发重平衡。等 GC 结束消费者恢复，队列里已经堆了 800 万条订单消息。 按正常消费速度，一个消费者每秒 200 条，800 万条要 11 个小时才能消化完。下游的物流、短信、积分服务全在等这条消费者的结果——11 个小时的延迟等于业务停摆。 这不是"能不能消费完"的问题。这是"等你消费完，用户早就不关心了"的问题。 我们当时做了一个临时救急：在不停原有消费者的前提下，多开了 10 个临时订阅组来瓜分积压。 一、为什么不能直接加消费者实例 第一反应是给原消费者组多加几个 Pod。但因为原有消费者的队列分区是固定的——假设 8 个 MessageQueue，原消费者组 8 个 Pod，每个 Pod 独占 1 个 Queue，已经分配好了。 直接加 Pod 到同一个组里没用——RocketMQ 是 Queue 粒度分配，8 个 Queue 最多 8 个消费者实例。加第 9 个 Pod 它会被晾在那，一个 Queue 也分不到。 也不能直接增加 Que....

做过 Kafka 消息消费的同学肯定都遇到过这个问题：由于生产速度突然激增或者消费者处理能力不足，消息队列里堆积了大量未消费的消息。看着监控面板上的消息堆积数不断攀升，心里真是慌得一批。 我之前就遇到过这样一个案例：某天晚上，由于上游系统突发故障，导致某个 Kafka Topic 的消息堆积量从平时的几百条突然涨到了 500 万条。消费者线程一直在满负荷运行，但消息堆积还是越来越严重。如果不及时处理，消息积压会导致数据延迟、消费者超时，甚至整个服务崩溃。 今天我们就来聊聊 Kafka 消息积压的紧急扩容方案，让您的系统在关键时刻能快速应对消息洪流。 消息积压的根本原因 1. 生产速度远超消费速度 这是最常见的情况： 场景：促销活动导致消息暴增 生产者：每秒产生 10000 条消息 消费者：每秒处理 1000 条消息 结果：每秒积压 9000 条消息 1 分钟：54 万条积压 10 分钟：540 万条积压 2. 消费者处理能力不足 问题分析： - 单线程处理太慢 - 业务逻辑太复杂 - 下游服务响应慢 - 数据库写入瓶颈 3. Partition 数量限制 Kafka 的消费并行度限....