1. 消息队列消息持续积压 与消息队列满出现原因
MQ消息持续积压 与消息队列满出现原因 可以从生产者端与消费者端两个方面去思考，要么是发送端变快，要么是消费端变慢造成：
- Producer 端单位时间发送的消息增多，Consumer 端短时间内来不及消费；
- Producer 端单位时间发送的消息正常，Consumer 端因消费线程低效不能及时消费
2. 如何优化MQ性能避免消息积压
一定要保证Consumer端的消费性能要高于Producer端的发送性能，这样的系统才能健康的持续运行。
Producer 端发送消息的性能低，需要检查Producer 端发消息之前，是否因业务逻辑耗时太久导致；只需要注意设置合适的并发和批量大小，就可以达到很好的发送性能。
- 优化消费端的消费业务逻辑性能；
- 水平扩容，通过扩容Consumer端的实例数来提升总体的消费性能
1）先修复consumer的问题，确保其恢复原有的消费速度;
2）将现有consumer都停掉，新建一个Topic，Partition可以是原来的10倍，临时建立好原先10倍或者20倍的queue数量；
3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮 询写入临时建立好的10倍数量的queue;
4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据，这种做法相当于是临时将queue资源和consumer资源扩大10倍，以原来的10倍速度来消费数据；
5）等快速消费完积压数据之后，得恢复原先部署架构，重新启用原先的consumer机器来消费消息
必须同步扩容Topic中的Partition数量，确保Consumer的实例数和Partition数量相等，以最大化消费线程并发的利用率。
3. 消费端是否可以通过批量消费的方式来提升消费性能？
消费端进行批量操作，感觉和上面的先将消息放在内存队列中，然后在并发消费消息，如果机器宕机，这些批量消息都会丢失，如果在数据库层面，批量操作在大事务，会导致锁的竞争，并且也会导致主备的不一致。如果是一些不重要的消息如对日志进行备份，就可以使用批量操作之类的提高消费性能，因为一些日志消息丢失也是可以接受的。
