Troubleshooting系列-评论管理台接口超时问题定位分析

1. 问题现象

有一天下午运营反馈管理台评论外放接口操作老是超时,处理不成功。

2. 问题定位分析过程

2.1 收集信息

出现问题后首先查看PINPOINT监控,发现那天下午有很多管理台接口超时,超时接口大部分都是如下

sql 复制代码
update comment set xxx=?

然后在ELK上搜索相关容器日志,发现有很多数据库报错日志,报错信息如下

bash 复制代码
RecoverableDataAccessException ### Error update database ...

从上面两个地方可以看出可能是数据库存在问题,查看数据库可能存在问题。

查看对应数据库监控,发现流量和IO基本正常,数据库连接数也正常。 接着查看是否是存在大的事务或者锁表

sql 复制代码
// 检索InnoDB存储引擎中当前活动事务的信息,并按照它们的开始时间进行排序。
SELECT 
    trX_id,
    trx_state,
    trx_started,
    trx_weight,
    trx_mysql_thread_id,
    trx_query,
    trx_operation_state
FROM
    information_schema.innodb_trX
ORDER BY
    trX_started DESC;
// 发现两个活跃事务,一个trx_started是下午 16:19 没有对应的sql trx_mysql_thread_id为1
// 另外一个trx_started是 17:56 对应的sql update comment_a xxx trx_mysql_thread_id为2

//继续使用sql查询InnoDB存储引擎中的锁等待情况,以便了解哪些事务正在被阻塞以及它们正在等待的资源

SELECT r.trx_id AS waiting_trx_id, r.trx_mysql_thread_id AS waiting_thread, LEFT(r.trx_query, 30) AS waiting_query,
       b.trx_id AS blocking_trx_id, b.trx_mysql_thread_id AS blocking_thread, LEFT(b.trx_query, 30) AS blocking_query
FROM information_schema.innodb_lock_waits AS W
INNER JOIN information_schema.innodb_trx AS b ON b.trx_id = W.blocking_trx_id
INNER JOIN information_schema.innodb_trx AS r ON r.trx_id = W.requesting_trx_id
ORDER BY blocking_thread DESC;

//发现其中为waiting_thread 为2 blocking_thread为1的记录,说明2在等待1完成

// 查看innodb_lock_wait_timeout参数配置时间,待确认

发现有超常事务,事务从下午4点多已经开始,一直没有释放,运营保障时已经接近6点。

2.2 紧急规避问题

有长事务未释放不太正常,联系运维将此事务KILL调,管理台操作正常

sql 复制代码
KILL 1

2.3 继续分析问题

KILL调进程时间段搜寻ELK日志,发现有数据库连接相关的报错,根据连接堆栈找到具体报错代码。 结合代码分析大概原因如下:

主要原因有两个:

  1. thread1定时任务在获取需要外放的视频数据后,使用一个非常大的事务,并且在加@Transactional没有指定timeout
    • 默认情况下,@Transactional注解的timeout属性值为-1,表示不设置超时时间,事务将无限期等待直到执行完成或发生其他原因导致的回滚。
    • 每个视频外放操作比较复杂,需要调用风控判断视频是否能外放获取检测结果,成功后需要更新一系列缓存值,耗时较长
  2. 存在对评论更新操作死锁条件,存在业务表更新资源出现循环依赖情况

3.问题解决

此处主要讲述问题解决措施:

  • 临时解决方案:kill 定时任务事务,避免再次出现大事务,与运营沟通暂停视频外放定时任务,改为人工执行
  • 长期解决方案:
    *
    1. 破坏死锁产生条件,更新评论数据时,按照一致的顺序更新表
      1. 将视频外放大的事务拆小,每个视频外放一个事务,同时@Transactional增加超时时间
      1. 单个@Transactional拆小,保留其中数据库更新操作,其他如查询视频审核放在事务之外

4.举一反三

团队内加大对事务使用和死锁的认知,输出案例集和加入到编程规范中。

相关推荐
armcsdn几秒前
基于Docker Compose部署Traccar容器与主机MySQL的完整指南
mysql·docker·容器
该用户已不存在27 分钟前
不知道这些工具,难怪的你的Python开发那么慢丨Python 开发必备的6大工具
前端·后端·python
Xy91033 分钟前
开发者视角:App Trace 一键拉起(Deep Linking)技术详解
java·前端·后端
嘻嘻哈哈开森38 分钟前
技术分享:深入了解 PlantUML
后端·面试·架构
爱学习的茄子40 分钟前
JavaScript闭包实战:解析节流函数的精妙实现 🚀
前端·javascript·面试
vvw&43 分钟前
Linux 中的 .bashrc 是什么?配置详解
linux·运维·服务器·chrome·后端·ubuntu·centos
Dgua43 分钟前
🚀Promise 从入门到手写:核心方法实现全指南
前端·面试
厚道1 小时前
Elasticsearch 的存储原理
后端·elasticsearch
不甘打工的程序猿1 小时前
nacos-client模块学习《心跳维持》
后端·架构