今天又碰到了线上的故障。上午有客户反映网站某个操作没响应，打开监控一看数据库cpu占用又逼近100%了。后台日志不停地报获取不到连接的错误，但实际数据库连接数却并不是很高。检查配置发现有一个应用的配置有问题，连接数配太少了，而正是这个应用在报连接获取不到的错。于是调整了配置，顺便给两个表加了索引让查询再快一些。cpu占用很快就降了下来，似乎问题解决了。
没想到下午又出了同样的问题。这下可不是连接数配置的事儿了，看数据库慢日志也没有任何记录，但cpu占用就是居高不下。依然报获取不到连接，但如此高的cpu占用再增大连接数也没有任何意义。从监控上已经获取不到太多有价值的信息，只好从代码入手，希望能看出点端倪。
因为客户反映是在门店列表页进不去门店，看了下tomcat的status页面也是绝大部分线程都阻塞在这个请求上，所以就从这儿开始检查好了。结果一看果然看出了问题。
在这个地方程序员犯了一个比较明显的错误，在循环里去请求数据库，这样一次页面请求就会请求几十上百次数据库。这样一旦数据量稍有增加，访问量稍大就可能会造成严重的性能问题。正确的做法应该是什么呢？得具体问题具体分析，最好是从业务上就避免这样的设计。技术层面上的优化无非就是几种，保存中间结果避免反复查询，或者是使用缓存来减轻对数据库访问的压力。具体到这个问题，最简单直接的方案就是加个缓存。于是快速修改并上线部署，问题果然就随之解决了。
明天得把这几次解决问题的教训和心得跟团队分享一下。必须让整个团队变得能力更强跑得更快更远，这样才能迎接更大的挑战。
网友评论