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，服务器性能等。