1,mq积压如何解决?
2,我们怎么去排查mq积压的问题?
mq问题排查的核心:
1,mq消息队列消费不过来,查看管道和连接数据。
2,mq消息数据积压数据消费不过来,自动ack比手动ack快。
3,程序性能不行。
4,数据库锁表,数据库io过高也会导致数据积压。
5,增加消费者连接数配置。(不推荐)
我们消息队列积压了一千四百多万的业务数据,数据积压了会一直积压,如果不处理对业务有很大的影响。
我们看我们管道和消费都是正常的,所以程序处理慢的问题就在我们写的消费程序上面了。
我们排查到问题是因为程序的问题没有修改的程序代码:
这段代码的意思是用java程序写分析服务,虽然用的是orcal数据库,但是数据库io还是挺大的,导致了数据库锁表,频繁的添加和更新会导致数据库io过高,然后锁表导致mq消息消费不过来积压。
这条sql可以帮我们查看当前锁表的语句。
select b.username,b.sid,b.serial#,c.* from v$locked_object a,v$session b,v$sql c where a.session_id = b.sid
and b.SQL_ID = c.sql_id
order by b.logon_time;
那么找到问题了就好解决了,优化代码。
第二版本代码,优化了程序锁表问题解决了。消息也不堆积了。
但是redis缓存库也有压力啦。几百万个对象存redis还是不行。
第三版代码,平衡redis和数据库的操作,数据直接入库,通过定时任务去触发读取redis key进行更新数据,分析数据根据缓存去删除缓存和库的数据。定时更新数据库后删除redis缓存,通过字符串key判断数据是否存在。第三版代码就相对稳定了,我们问题已经解决了。
总结:基于大数据量,高并发下程序,我们一定要考虑数据库io和redis缓存的压力,并不是说所有的并发都可以通过缓存去处理,实际情况是复杂的多,既要考虑服务器性能,也要考虑数据库io和redis缓存过多的问题,还有程序本身代码的处理。通过均衡程序和缓存,数据库io的方式,并不是说读写改都不能操作数据库,有必要的时候取其二这样才能让程序稳定且高效的运行。
排查mq堆积的问题:1,管道连接,mq通讯。2,程序代码。3,数据库io。4,分布式缓存性能瓶颈。5,服务器性能等。