1. 消息队列消息持续积压 与消息队列满出现原因
MQ消息持续积压 与消息队列满出现原因 可以从生产者端与消费者端两个方面去思考,要么是发送端变快,要么是消费端变慢造成:
- Producer 端单位时间发送的消息增多,Consumer 端短时间内来不及消费;
- Producer 端单位时间发送的消息正常,Consumer 端因消费线程低效不能及时消费
2. 如何优化MQ性能避免消息积压
设计MQ系统的时候,一定要保证Consumer端的消费性能要高于Producer端的发送性能,这样的系统才能健康的持续运行。
2.1 发送端性能优化
Producer 端发送消息的性能低,需要检查Producer 端发消息之前,是否因业务逻辑耗时太久导致;只需要注意设置合适的并发和批量大小,就可以达到很好的发送性能。
2.2 消费端性能优化
- 优化消费端的消费业务逻辑性能;
- 水平扩容,通过扩容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机器来消费消息
3. 扩容Consumer的实例数量的同时,必须同步扩容Topic中的Partition数量,确保Consumer的实例数和Partition数量相等,以最大化消费线程并发的利用率。
3. 消费端是否可以通过批量消费的方式来提升消费性能?
消费端进行批量操作,感觉和上面的先将消息放在内存队列中,然后在并发消费消息,如果机器宕机,这些批量消息都会丢失,如果在数据库层面,批量操作在大事务,会导致锁的竞争,并且也会导致主备的不一致。如果是一些不重要的消息如对日志进行备份,就可以使用批量操作之类的提高消费性能,因为一些日志消息丢失也是可以接受的。
参考: