实践案例：使用观测云排查数据库死锁故障

故障发现

核心应用 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 ，可以判断，没有执行事务提交操作，从链路关联的日志中，也能佐证这一点。