RocketMQ/Kafka：百万或千万消息积压处理，快速处理思路。
发生了线上故障，几千万条数据在 MQ 里积压很久。是修复 consumer 的问题，让它恢复消费速度，然后等待几个小时消费完毕？这是一个解决方案。不过有时候我们还会进行临时紧急扩容。
一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟是 18 万条。1000 多万条，所以如果积压了几百万到上千万的数据，即使消费者恢复 了，也需要大概 1 小时的时间才能恢复过来。
一般如果消息不重要的话就在 consumer 上直接释放掉。 如果 topic 的 messageQueue 设置的比较多，比如设置了 20 个，consumer 实例只有 4 个，那么每个 consume 实例对应 5 个 messageQueue，这个时候可以申请临时增加consumer，比如增加 consumer 实例为 20 个，达到快速消费的目的。
如果 messageQueue 设置的比较少，比如只设置了 4 个，那么这个时候就不能通过加 consume 机器来解决了，这时候就需要修改消费者代码了，不直接在消费者中消费，而是把要消费的消息放到 MQ 的另一个 topic 中，这个 topic 设置 20 个 messageQueue，对应 20 个 consumer 实例，进行消费。
发生了线上故障，几千万条数据在 MQ 里积压很久。是修复 consumer 的问题，让它恢复消费速度，然后等待几个小时消费完毕？这是一个解决方案。不过有时候我们还会进行临时紧急扩容。
一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟是 18 万条。1000 多万条，所以如果积压了几百万到上千万的数据，即使消费者恢复 了，也需要大概 1 小时的时间才能恢复过来。
一般如果消息不重要的话就在 consumer 上直接释放掉。 如果 topic 的 messageQueue 设置的比较多，比如设置了 20 个，consumer 实例只有 4 个，那么每个 consume 实例对应 5 个 messageQueue，这个时候可以申请临时增加consumer，比如增加 consumer 实例为 20 个，达到快速消费的目的。
如果 messageQueue 设置的比较少，比如只设置了 4 个，那么这个时候就不能通过加 consume 机器来解决了，这时候就需要修改消费者代码了，不直接在消费者中消费，而是把要消费的消息放到 MQ 的另一个 topic 中，这个 topic 设置 20 个 messageQueue，对应 20 个 consumer 实例，进行消费。
