故障发现
核心应用 pod 发生重启，同时接收到对应使用者反馈业务问题，开始排查。
观测云排查现场
1、根据重启应用信息，查询 APM 执行数据库 update 操作大量报错，执行时间在 5min 以上。
分析 APM 链路异常，发现是触发了数据库的等锁超时，结合数据库等锁超时时间为 5min ，符合预期。
2、查看对应数据库指标，问题时间段等锁耗时、行锁、每秒锁表数据指标异常， 并且在 11:13 分出现死锁。
3、日志关键字搜索“Deadlock”，发现有数据库出现死锁，发现 11:13 分有死锁日志。
初步结论
数据库死锁，导致了本次故障发生，需要进一步分析死锁出现的原因。
进一步排查
数据库死锁日志的部分截图。
- 对比左右两份日志，发现是同一个事务 ID ，
TRANSACTION 367507261，事务持续了 7 分钟。 - 对应 update 了两个表，左侧执行 update A ， 右侧执行了 update B 。
- 开发排查代码发现， A 表 和 B 表不在一个接口里， 也就是说不可能同时出现在同一个事务中，但数据库日志却得出在一个事务中。问题显得非常诡异。
这里，首先应该确认的一点，数据库事务 ID 是不会出问题的（期间也怀疑过，找 DBA 确认过数据库无问题） ，那极有可能是事务混乱了，应用使用的 spring 框架，使用的是 HikariCP 的数据库连接池，连接池是多线程的，现在假设一种场景，请求 1 使用了一个数据库线程，开启了事务，但是并没有提交事务就结束了，这个线程放回线程池，过了一段时间请求 n 进入直接进入了这个事务， 并开启了子事务进行数据库操作，那么就极有可能发生死锁如下图：
开发复盘整个代码， 发现有代码在 controller 层显示开启了事务，也有显示的提交，但是中间存在逻辑漏洞会直接 return 不关闭事务。
##伪代码
method A {#开启事务transcation.start();A = db.select()if (A == null) {return "数据异常";}db.update();transcation.commit();return success;
}
观测云查询作证，确实执行到“查询失败”直接返回到逻辑。 和猜想一致。
对比链路，正常链路会有一个 SELECT， 随后跟一个 UPDATE 。
异常链路中，仅执行了 SELECT ，可以判断，没有执行事务提交操作，从链路关联的日志中，也能佐证这一点。
