记一次.Net分布式事务死锁现象以及解决方法
在本文中，将介绍一次遇到的.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及以上版本的特性，自动将同一个分布式事务范围内的远程调用整合到一个网络请求中。这样，如果调用的服务属于同一个进程，它们将被安排在同一个作用域中，从而保证获取到的数据库对象是同一个。
通过以上解决方法，可以有效避免分布式事务死锁的发生。
