前几天&＃xff0c;春节过完开工第一天&＃xff0c;结果运营就反应生产环境有BUG了。真是“开门红”啊~~~

先和运营了解到线上的问题症状&＃xff0c;然后就连接生产服务器&＃xff0c;开始逐步排查了&＃xff01;

2.1 生产环境的问题症状

症状一&＃xff1a;查询列表的数据&＃xff0c;有的数据会时有时无&＃xff01;&＃xff08;如ABCD四条数据&＃xff0c;刷新页面&＃xff0c;B数据时而出现&＃xff0c;时而没有&＃xff09;

症状二&＃xff1a;新建订单&＃xff0c;创建成功后&＃xff0c;数据并没有入库

前面两点是通过web端页面操作&＃xff0c;所反映出来的异常情况&＃xff01;后续我们通过查看日志&＃xff0c;还发现了另外两种日志异常&＃xff01;&＃xff01;&＃xff01;

症状三&＃xff1a;程序接口会报数据库事务锁定异常&＃xff0c;如下&＃xff1a;

### Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction
; Lock wait timeout exceeded; try restarting transaction; nested exception is com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Lock wait timeout exceeded; try restarting transaction


症状四&＃xff1a;数据库无法连接异常&＃xff0c;如下&＃xff1a;

Caused by: java.sql.SQLException: connection disabled

2.2 分析

①对于症状一&＃xff0c;查询数据时有时无的情况&＃xff0c;分析&＃xff1a;

• 用了缓存&＃xff0c;缓存失效导致
• 列表结果不一致的&＃xff0c;是因为请求到了两个不同的服务上&＃xff08;即分别请求到不同的两个进程了&＃xff09;

②症状二分析&＃xff1a;

• 提交请求&＃xff0c;发送到了其他服务上
• 数据库配置问题&＃xff0c;导致数据插入到了别的数据库

③症状三分析&＃xff1a;

• 数据库锁表&＃xff0c;导致事务阻塞&＃xff0c;被锁
• 数据库事务的传递性没有正确配置
• 事务未正确开启和关闭导致事务阻塞

④症状四分析&＃xff1a;

• 数据库配置出了问题&＃xff0c;导致数据库不可连接
• 服务器与数据库之间的连接有问题

2.3 解决

本篇主要是针对症状三&＃xff0c;进行分析解决&＃xff01;所以其他的问题&＃xff0c;此处暂且不做解决方案叙述了~&＃xff08;目前问题都已经解决了&＃xff0c;如有兴趣的朋友&＃xff0c;可以下方留言探讨&＃xff09;&＃xff01;

上面已经对问题进行了几个方面的分析&＃xff0c;所以按分析的方向&＃xff0c;开始逐一排查&＃xff01;

①首先&＃xff0c;查询数据库&＃xff0c;查看是否有被锁表的情况&＃xff1a;

-- 查看正在被锁定的的表show OPEN TABLES where In_use > 0;in_use:多少个线程在使用name_locked:是否被锁-- 查询哪些线程正在运行show processlist;-- 最关键的就是state列-- 查看正在锁的事务SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;-- 查看等待锁的事务SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

通过上面的查询之后&＃xff0c;发现数据表并没有被锁死的情况。所以锁表导致的事务异常&＃xff0c;可以排除&＃xff01;

②排查程序中数据库事务传递性的配置&＃xff0c;但是我们使用的是默认配置&＃xff0c;即&＃xff1a;

//支持当前事务&＃xff0c;如果当前没有事务&＃xff0c;就新建一个事务。
PROPAGATION_REQUIRED

所以&＃xff0c;事务传递性导致的可能性&＃xff0c;也基本可以排除了&＃xff01;

③事务是否没有被正确的开启和关闭呢&＃xff1f;答案是肯定的&＃xff01;&＃xff01;

后来&＃xff0c;从代码层面排查事务的使用情况&＃xff0c;结果发下如下代码&＃xff1a;

try{TransactionStatus status &＃61; super.openTransaction("createStockEntrustOrder", TransactionDefinition.PROPAGATION_REQUIRED);boolean validResult &＃61; stockEntrustList.stream().anyMatch(s-> !this.checkOrderParam(s));if(validResult) return new CommonResultVO(ResultConstant.PARAM_ERROR);............transactionManager.commit(status);
}catch (Exception e) {......transactionManager.rollback(status);return new CommonResultVO(ResultConstant.FAIL);
}


问题来了&＃xff1a;此处有一个校验返回的处理&＃xff0c;就在开启事务之后&＃xff01;那么此时就可能出现&＃xff0c;校验没通过&＃xff0c;接口中的事务开启了&＃xff0c;但是因为直接return&＃xff0c;导致事务没有被正确关闭掉&＃xff01;&＃xff01;&＃xff01;如果类似情况&＃xff0c;出现多次&＃xff0c;就很有可能造成事务的阻塞&＃xff0c;锁定异常的情况的发生&＃xff01;

解决方式&＃xff1a;将此处的代码进行调整&＃xff0c;在return的地方进行事务的回滚操作&＃xff01;&＃xff01;&＃xff01;或是&＃xff0c;使用注解事务

&＃64;Transactional(rollbackFor &＃61; Exception.class)

最终&＃xff0c;此症状得以修复&＃xff01;&＃xff01;&＃xff01;

通过此次问题的暴露&＃xff0c;个人总结两点原因&＃xff1a;

• 写代码的时候&＃xff0c;不够仔细&＃xff0c;代码逻辑处理不够严谨
• 代码编写完成或是测试前&＃xff0c;没有进行自我Review&＃xff0c;查缺补漏

所以&＃xff0c;记录此篇文章&＃xff0c;引以为戒&＃xff0c;往后Coding时&＃xff0c;需更加的谨慎&＃xff0c;并要有良好的代码review习惯&＃xff0c;减少bug的出现&＃xff01;&＃xff01;&＃xff01;

如果此篇文章有帮助到你&＃xff0c;或是有不足的地方&＃xff0c;欢迎留言探讨&＃xff0c;共勉~~~~