记一次.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及以上版本的特性，自动将同一个分布式事务范围内的远程调用整合到一个网络请求中。这样，如果调用的服务属于同一个进程，它们将被安排在同一个作用域中，从而保证获取到的数据库对象是同一个。

通过以上解决方法，可以有效避免分布式事务死锁的发生。