记一次关于golang使用xorm访问mysql事务不关闭引发的问题

事件还原：项目经理带客户体验公司的产品，发现机器前端提示网络异常，鉴于近期阿里云和腾讯云都发生过网络问题没有排查原因。过阵子，测试的同事跑去问qt前端的同事说网络这么久还异常啊。qt前端同事自己测试了一下，发现确实接口“有去无回”，就问了下后台的同事看看接口是否调的通。由于他们看的是心跳接口，后台同事一看，有些调用成功。然后就说可能是网络不稳定。ok，刚好后台同事写好需求同步服务后，qt前端的同事跑来问我和维护的同事说网络怎么这么差呀。维护的同事到他们机器上看，网络延迟不大，就说你别用你代码跑，用postman发个http请求试试看，结果qt前端的同事当着我们的面在postman上给后台服务发了好几个http请求，马上就接收到请求。然后再跑qt前端同事的代码，还是“有去无回”，然后我和维护组的同事就没看下去了觉得可能就是qt前端同事的问题，大赞维护组同事定位经验。几天过去了，qt前端的同事又跑过来问我说他检查了n遍，确定真的不是他的问题，而且用postman发http请求现在也不行了，肯定是网络问题。我登上设备ping了下服务器地址并telnet一下后台服务端口发现端口是通的，网络延迟也不大，并让qt同事发送错误的参数给后台，发现秒回。ok，让后台同事在心跳接口上打印日志，后台同事加上日志重启服务，接口调用又正常了。前端同事和后台接口开发的同事又说，肯定是网络问题，又重现该问题。我就让后台同事去定位一下，觉得应该跟前端没关系，并看了下后台心跳接口的日志，发现日志卡在调用数据库前，莫非是数据库除了问题，就用navicat premium用相同的语句访问了一下数据库，发现很快就返回了。在看看数据库的工作进程，发现后台服务开了好多个链接，还有好多个链接sleep时间特别长。ok，排除下代码，直接到后台代码根目录敲grep “NewSession” ./ -r -n -A 10，锁定确实是后台同事使用xorm时，为了开启一个事务启用session后没有关闭，大量session处于sleep状态，当到达一定量后不同配置会有不同的处理，比如返回错误或者等待获取一个session。

总结：
当后台服务启动一段时间后不能正常访问数据库，可以考虑是否是因为代码中有使用了session后没关闭。