蝴蝶效应与“数据库慢查询雪崩“

        昨天是周四，下午进行了平淡无奇的大屏数据排查问题，随后部署升级。傍晚，忽然系统大屏界面出现个别的报错:"网络连接超时，请重试"。
        瞄了一眼后，发现是前端调用后端接口外部数据源查询超时，而且这些接口最近没有太大的改动。随即找其他平台同事沟通、反馈，得到了一切正常的答复.... 

       于是博主觉得可能是网络延时、卡顿问题（在用VPN），就没再注意了。

        第二天，晨会后再查看门户大屏数据，出现了雪花般的报错，瞬间就清醒了.....

 

       排查一番系统后，发现登录功能、后台用户管理功能一切正常，只有大屏数据异常。博主觉得还是数据库查询慢问题，就找其他平台同事开会沟通问题，得到了可能是新增sql关联的表业务太多。

     

      灵光一闪，博主隐隐感觉还是不太对，开始查询服务器详细日志，发现数据库日志出现大量的DM报错日志。仔细一看，发现是连接池获取数据库连接超时。

       博主想了想数据库连接池配置，150个最大连接，加上数据库连接池的空闲回收、定时清理机制，不应该会出现在这个“几并发”的业务场景。   

     

 博主仔细分析了下，有了一个大概的猜测：

1）DM数据库性能有点异常（诱因问题） 

2）部分代码写的不太规范，导致问题1翻倍（隐藏问题） 

结论：不规范代码占用数据库连接池不释放。刷新几次页面，新来的HTTP请求导致所有的数据库链接都被慢SQL占用。其他HTTP请求进来，就会等待从连接池中获取可用链接，超过15s后，浏览器端断开了请求。而后端的HTTP请求线程还在等待，等到30s后，则获取数据库连接超时，就抛出了如上图所示的异常问题。
       

有了这个思路，博主就开始尝试临时解决下问题：

1）设置数据库查询超时时间 

2）增大数据库连接池最大个数到300...   

由于1)还要改代码，所以博主直接改了2），增到了500。信心满满的重启了服务。
结果：

       

         

        博主经过一番痛定思痛，意识到临时解决2)是不可取的，1)还行。但还是要解决下系统数据库连接池连接被占满的根源问题---》代码不规范问题。 Ex：for循环查询库...没意义的查询等等...

   做了上述操作，博主就开始顺便让同事排查每个模块功能的代码、SQL，进行实际测试、验证、筛选问题代码、慢SQL。

        下午和同事评审这些问题代码、SQL。最慢的一个统计接口查询耗时能够达到78s..... 而且部分sql查询达到了 22s以上。

         至此，问题基本上都有了定位。后续外部主要和其他平台同事排查 sql查询超级慢的问题。内部同时开始Review问题代码，也在在线文档上给出了每个接口的修改意见。

         再后面，博主修复了部分接口，重新部署、升级了服务，系统貌似暂时恢复了正常。  

     

        总结：这是一次由于DM数据库异常超时的蝴蝶在 系统不规范代码（7*5层循环，翻几十倍）的翅膀煽动下，刮起了一阵风（单次HTTP请求长期占用链接），最终引起了隔壁大洋海啸（系统整个大屏数据统计全都宕机）的故事。  

        个人：代码规范性才是最值得我们开发人员需要注意的。要带着思考去写代码，而不是为了工作写代码。

        THANKS~~