消费者挂了半小时，RocketMQ里堆了800万条消息，恢复后消费了6个小时
那天下午，库存服务一次 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....
