携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第1天，点击查看活动详情
问题出现
数据库死锁的问题不知道大家有没有见过，反正我干了三年多CRUD是第一次见。
接下来就一起来看看我遇到的这个死锁到底是怎样造成的？怎么解决的？
首先贴一下报错信息
### Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException:
Deadlock found when trying to get lock;
try restarting transaction; SQL [];
Deadlock found when trying to get lock;
try restarting transaction;
nested exception is com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException:
Deadlock found when trying to get lock;
复制代码当时的业务逻辑大概是这样的，如下图
现在给他简化一下
- 两个接口A和B，分别会开始事务A和B,一条数据行d
- 首先接口A会开启事务A去更新数据行d，拿到这条数据行的锁
- 通过RPC调用接口B，接口A等待接口B的响应返回才能进行事务的提交
- 接口B开启事务B去更新数据行d,但是数据行d的锁被事务A持有，事务B只能等待事务A释放锁才能进行数据的更新
这就是典型的相互等待造成的死锁，一个持有锁，一直无法释放；一个等待锁，一直获取不到。
那么，这个问题是如何解决的呢
经过跟同事及leader的沟通，大概给出三种方案
多线程
针对上面造成死锁的问题，可以将RPC的调用另起一个线程去执行；主线程去执行数据更新的操作。
- 首先接口A不需要等待接口B的返回就可以提交事务
- 然后就算接口B执行比较快：A事务还没有提交的时候，B接口就已经执行到更新数据的地方，这时候会堵塞；但是没关系，无论如何A事务都会提交事务，无非是快慢的问题
- 所以上述的死锁就会被解决
但是这种方式就是万无一失么，有什么问题呢？
- 多线程执行RPC调用，无法获取响应结果（当然多线程也能获取结果，但是获取结果的话，事务A还是无法提交造成死锁，没有意义）。
- 无法判断接口的成功与否，就丧失了事务失败回滚的意义
- 多线程能解决上述问题的死锁问题，但是稍微复杂一点的多表交叉更新还是会出问题，如下图
对事务进行细化处理
把接口A中的事务进行细化拆分：
- 将需要更新数据库的逻辑拆分成一个方法，并在方法调用的时候开启事务
- 当细分的方法执行成功后，再去进行RPC调用
这个解决了响应无法返回的问题，但还是那个问题，如果RPC调用失败了，更新的数据无法回滚。
顺序处理（也是最终的处理方案）
上述死锁问题的解决
- 先RPC调用接口
- 再进行更新操作
另外，顺序处理也是能解决复杂一点的多事务的多表更新死锁问题的。
首先我们得保证两个或多个开启事务的接口，对数据库数据的处理尽量避免交叉更新，应该按顺序更新。
比如对多线程处理的第三个问题解决，如图
其他方案
大伙们还有其他比较好的方案么，欢迎来沟通讨论啊。