记录一次项目部署的问题

出现的问题

正式服务器上的服务更新后，晚上6点定时任务启动，服务失去响应，后台页面打不开，连接的设备逐渐离线。

查找原因

1. 第一时间连上服务器查看项目的日志，发现日志不断的在滚动针对某几张数据库表的查询日 志，根据日志内容，可以判定后台正在执行下发资源的业务。业务本身需要大量的数据操作，但历史版本在执行对应操作时，却不会导致页面连接超时。
2. 思考到更新后版本异常，而更新前正常，便去对比此次修改的代码，是否多删除了某些代码。经过简单的比较发现此次更新的代码并不会对该业务产生影响。
3. 思考是否是缓存配置失效，导致原本走入缓存的请求全部压到了数据库上。先检查了配置文件，发现Redis缓存正常，进入Redis查看缓存数据，也是正常。
4. 确定缓存配置无误后，任然不能排除缓存异常的嫌疑。既然配置无误，便有可能是使用缓存的地方有误，找到业务开始代码，初步浏览后发现：原先为测试环境注释掉了去缓存、对比缓存的代码，而此次部署正式环境时却为注意到该段代码。此时才如梦初醒，急忙解开注释，重新打包，重新部署，启动项目后，希望以前正常，但是，事与愿违啊！问题还是依旧，看来不止这一处有问题。
5. 重新打开查看日志，发现日志中访问数据库的SQL语句并未有明显得减少。思考是否是解开的缓存并未生效？本地调用接口测试发现缓存已经生效，凡是能定位到缓存的请求都能正常返回，而需要走到数据库的请求都会超时。
6. 此时想到是否和数据库有关，对比数据库连接，没有发现异常，查看数据库连接池配置，发现线上版本提供的数据库连接池最大才给到100，而上个版本的服务给到了300，是否会是数据库连接池给的不够呢？抱着死马当活马医的态度，重新修改了数据库连接池，给到了300，重启项目后，发现日志滚动依旧很频繁，前端依旧处于无法显示的状态，而在等待了一段时间后，日志滚动恢复正常，急忙打开首页，一切正常。此时问题才算是初步解决。

问题后续

在和客户“交流”后 ，算是告一段落，不过问题出现到解决持续时间比较长，客户一直打电话给上司，甚至正面硬怼了老大。感觉自己心里挺不好意思的，自己的问题，却要老大背锅。不过还是非常感谢老大，虽然他在回家的火车上没有提供到什么实质的帮助，但是没有硬怼我，而是教我一步步的定位问题。虽然大多数的建议最后都被证实不是引发本问题的罪魁祸首，但是我还是非常感谢。

问题反思

此项目是一个闲置了一段时间的项目，项目完成后部署后便立即投入了下一个项目的开发中，平时也就是上去改改小东西，导致此次更新大版本时都已经忘记了自己上次把缓存给注释了，也忘记了将连接池改小了（本次测试不允许拥有那么多的连接数）。便导致了今天的问题，其实所有的原因都是因为自己的不细心，作为一名软件开发工程师，粗心真的是一个非常非常非常严重的问题，需要引起足够的重视。立此贴为证，我给自己定下一个规矩：今后凡是部署项目，项目启动后，需要一个个检查对应的配置文件是否配置正确，争取杜绝今天的事件重演。