消息积压在MQ中是一件很正常的事，但是积压过多了，就可以会导致消息的丢失，甚至系统的崩溃。那我们从事前的预防和事后的处理两个方面去解决。
一、事前预防
我们如何预防消息积压呢，一般就是批量和增加并发这两个方法，发送端和消费端都可以从这两个方面去处理。
1.1 发送端
1.批量。比如一次从数据库中批量查出数据发送mq。
2.增加并发。多线程并发处理
1.2 消费端
我们常用的一个做法是收到一个mq消息后，直接放入一个内存队列中，返回mq确认，后台再多线程并发处理。虽然消费的速度加快了，但是这里有一个问题，此时消费端宕机了，内存队列的数据就会丢失，这条消息就会丢失了。所以我们必须处理完消息才能给mq发送消息确认。
增加消费端consumer的实例数量的同事，必须扩容主题中队列的数量，确保consumer的是实例数和队列数是相等的。至于为什么必须扩容队列数量，因为在同一个队列中是单线程处理的，如果队列数量没有增加，那么即使增加了consumer的数量，消费的速度也没有增加。
二、事后处理
如果生产上出现了消息积压过多，我们又该如何处理呢？必须先将积压的消息快速消费掉后，再慢慢找原因。
一般消息积压无非两个原因，发送过快或者消费过慢，我们可以通过mq的监控确定是那个端出现了问题。
1.发送过快。消费端的速度赶不上发送的速度。
1.1 紧急扩容消费端实例，快速消费消息。
1.2 如果没有足够的服务器扩容，系统降级，将一些不重要的任务关闭，减少发送端的数据量，优先处理积压的消息。
2.消费过慢。检查日志查看错误原因，打印堆栈信息等查看是否发生思索或者等待某些资源导致消费很慢。
3.如果发现发送和消费的速度和往常差不多，需要检查日志是否有消息是否消费失败了，导致一直反复消费。