oracle bs开发,梁晓龙：一次基于Oracle数据库BS业务架构的全方位优化实践

一个老牌传统行业客户出现了业务界面报错、中间件卡顿、数据库性能差的问题，最直接的表现是业务人员在登录业务系统进行操作时候出现加载缓慢、页面丢失的情况，导致业务人员对于系统诟病无数，影响业务正常进行的同时，也让业务小伙伴很抓狂。到现场后，主管业务系统的甲方同志素质好、形象佳、有才华、大高个、态度和蔼、乐呵呵。把问题描述的很清楚，这点让我们的工作比较容易开展起来。

基本痛点如下：

1、业务用户登录系统出现大量页面丢失问题。

2、 即使登录后，由于业务用户的连接，中间件出现大量粘滞进程，中间件的负载分担也不平衡，导致中间件某个节点宕机。

3、 数据库在查询时期出现卡顿。

一般对于遇到问题的初步做法，我的习惯可以概括为两个字：“瞎猜”。

对于这样的架构，首先映入眼帘的是这样的印象，由于客户采用的是B/S结构，而且整个架构当中并没有采用MQ等队列产品，这样设计的问题是容易在大量session加持下发生，将资源的争用延伸到数据库的后端，虽然在weblogic层面可以设置队列等待，但是weblogic 在等待队列超过一定时间后就会放弃重试，报出overload的错误，用weblogic 的连接池来限制数据库连接也不是专业的做法。所以，有没有可能大量的资源争夺放到了后端的数据库中产生了等待。这时候就涉及到了一个并发量的问题，如果是12306那样的并发，那基本上就可以确定问题，所有连接涌入数据库，数据库死导致中间件死导致页面丢失导致各种问题导致全死。问了下客户，基本连接为月底高峰时候每天300左右，平时很少，而且特别重要的一点是“并发少”，之前的峰值都是累计数值。那，应该是猜错了。

猜过了两个问题，还有个中间件的问题，中间件宕机的话，可能原因很多，中间件也会给出提示，比如内存溢出、连接池overload等。但是出现粘滞线程问题的话，大多是并不是线程问题，而是在对数据库连接的时候出现了返回内容量大、返回时间长的问题，其实看似是中间件问题，更多的是SQL优化的问题。