原因
测试在执行批量下单的时候报了一个非法参数，前端说是第一次调用接口报错 第二次传参异常导致，前端传参异常他已经修复主要是要排查到第一次的异常，返回的错误信息为：
cn.com.glsx.dj.smartcarlife.service.OrderDayReportService.updateTotal,lockName:OrderDayReportService_44211025_1_Mon Oct 30,threadName:DubboServerHandler-192.168.3.177:9073-thread-198 get lock timeout in 10 SECONDS.
大概意思就是分布式锁超时
排查
查看日志发现数据库还有死锁情况
MySQL使用 show engine innodb status 命令查看最近的死锁日志
在输出日志找到死锁的SQL语句 结合代码分析死锁原因
分析结果
根据id更新同一张表的时候用到是行锁正常情况下是不会死锁的，有种特殊情况在主流程里面和所包含的异步线程有两个地方更新日报信息且执行顺序是相反的，事务一在执行A的更新操作的时候 事务二在执行B的更新操作 随后事务一执行B的更新操作 事务二执行A的更新操作 导致事务一、事务二等待彼此锁释放没法提交事务然后死锁 死锁的同时切面上的分布式事务也超时了（超时时间10S）
PS：事务范围大于分布式事务（aop实现）
673
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
