1、场景：上千万条消息在mq里积压了几个小时了还没解决
1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉 2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量 3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据， 消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue 4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据 5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据 6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息
2、场景：rabbitmq设置过期时间的，就是TTL
如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。
那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢
丢了大量的消息。我们可以采取一个方案，就是批量重导，这个时候我们就开始写程序， 将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来