在本文中,将介绍一次遇到的.Net分布式事务死锁现象以及解决方法。我们将首先了解事务框架的构成,然后分析导致死锁的代码,最后提出解决方法。
事务框架
本次开发框架JMSFramework将分布式事务划分为4个阶段,分别是:执行、确认、提交和重试。
1、执行
调用微服务来执行相关的业务操作。如果其中任何一个服务执行抛出异常或者宕机,那么所有的事务都会回滚。
2、确认
这个阶段会向各个微服务发送确认请求,主要目的是校验一下当前的网络是否正常,微服务有没有宕机,如果这个阶段有任何异常,那么所有的事务都会回滚。
3、提交
首先JMSFramework会通知网关,标识这次分布式事务为成功状态。(如果通知网关失败,则回滚所有事务)
然后通知各个微服务提交事务,确保所有的操作都已经完成。
如果某个服务提交事务失败,不会影响其他服务提交事务。
4、重试
有很小的机率会执行到此阶段。
当某个微服务在真正提交事务的时候发生意外宕机,导致事务没有成功提交。一旦服务器重新启动后,它会向网关咨询,并得知该事务已经被标记为成功状态。这时,系统会自动重新执行相关的业务代码,并提交事务,以确保数据的一致性。
产生死锁的代码
接下来我们看看触发死锁的代码:
using ( var client = new RemoteClient(gatewayAddrs))
{
//标识后面的调用需要启用分布式事务控制
client.BeginTransaction();
//获取服务接口
var accountService = await client.GetMicroServiceAsync("UserAccountService");
var giftService = await client.GetMicroServiceAsync("UserAccountService");
//扣除指定用户100积分
accountService.InvokeAsync("UseMemberPoints", userid , 100 );
//把某个礼品赠予指定用户
var ret = await giftService.InvokeAsync<GiftResult>("GiveGiftToUser", giftid, userid);
if(ret.GiftsReceivedCount > 10)
{
//如果累计收取礼品大于10个,升级用户vip等级
accountService.InvokeAsync("UpgradeVip" , userid);
}
//提交分布式事务
await client.CommitTransactionAsync();
}
这是一段调用几个微服务的代码,功能是:扣除用户100积分,同时把一个礼品转给这个用户,如果发现此用户累计已经兑换超过10个礼品,那么提升此用户的vip等级。
代码很简单,看不出有什么问题,并且上面所调用的三个接口函数,也都是通过了单元测试。
但运行后却发现卡死在client.CommitTransactionAsync()。
看来是调用某个服务卡住了,当我把每个调用都加上await后,发现其实是卡在了await accountService.InvokeAsync("UpgradeVip" , userid);
经过查阅代码,得知该函数会去更新用户信息表,而扣除用户100积分的函数也会去更新用户信息表。由于这两个函数在不同的线程中执行(服务调用属于远程请求,每次请求都是一个独立的线程),它们都要锁定同一个资源,因此只会有第一个线程成功更新,但由于数据库事务不会立即提交,而是最后一起提交,因此该用户数据会一直被锁定。第二个线程无法获取锁,更新语句也一直无法执行。由于第二个线程被阻塞,代码无法执行到client.CommitTransactionAsync(),导致事务无法提交,锁也不会被释放,这就形成了死锁。
解决方法
问题的根本不是两个线程锁定同一个资源,而是两个不同的数据库对象锁定同一个资源。如果这两个线程使用的是同一个数据库对象和同一个数据库事务,就不会出现这个问题。
因此,解决方法如下:
-
数据库对象作用域管理:使用AddScope方式依赖注入数据库对象,确保在同一个作用域中获取的数据库对象是同一个。
-
利用JMSFramework特性:利用JMSFramework 5.0及以上版本的特性,自动将同一个分布式事务范围内的远程调用整合到一个网络请求中。这样,如果调用的服务属于同一个进程,它们将被安排在同一个作用域中,从而保证获取到的数据库对象是同一个。
通过以上解决方法,可以有效避免分布式事务死锁的发生。
标签:事务,死锁,client,线程,提交,Net,分布式 From: https://www.cnblogs.com/IWings/p/17531275.html