事务中死锁重试

Question

我有 C# 窗口服务，它与 MS SQL 服务器上的多个数据库进行通信。它是多线程的，具有许多函数，每个函数都有很长的数据库操作列表，每个函数都在自己的事务下运行。所以一个典型的函数就像

    public void DoSomeDBWork()
    {
        using (TransactionScope ts = new TransactionScope(TransactionScopeOption.RequiresNew))
        {
            DatabaseUpdate1();
            DatabaseUpdate2();
            DatabaseUpdate3();
            DatabaseUpdate4();
            DatabaseUpdate5();

            DatabaseUpdate6();

        }
    }

在重负载下我们遇到了死锁。我的问题是，如果我编写一些 C# 代码来在发生死锁时自动重新提交 DatabaseUpdate，它会保留未提交操作的资源吗？例如，如果 DatabaseUpdate6() 中发生死锁异常，并且我在等待 3 秒的情况下重试 3 次，在此期间，所有未提交的操作“DatabaseUpdates 1 到 5”将保留其资源，这可能会进一步增加更多僵局？在出现死锁的情况下重试是否是一个好习惯？

Answer 1

你找错了树。

死锁意味着整个事务范围被撤销。根据您的应用程序，您也许可以从 using 块重新启动，即。一个新的 TransactionScope，但这非常非常不可能是正确的。您看到僵局的原因是其他人也更改了您正在更改的数据。由于大多数更新都将更新应用于之前从数据库读取的值，因此死锁清楚地表明您所读取的内容已更改。因此，应用更新而无需再次读取将覆盖其他事务更改的任何内容，从而导致更新丢失。这就是为什么死锁几乎永远不会“自动”重试，必须从数据库重新加载新数据，如果涉及用户操作（例如表单编辑），则必须通知用户并重新验证更改，然后才能再次尝试更新。只有某些类型的自动处理动作可以被退出，但它们永远不会像“尝试再次写入”那样重试，但它们总是在“读-更新-写”循环中运行，死锁将导致循环再次尝试，因为他们总是以“阅读”开头。它们会自动进行自我修正。

话虽这么说，您的代码死锁很可能是因为在不需要时滥用序列化隔离级别： 使用新的 TransactionScope() 被认为是有害的。您必须覆盖事务选项才能使用 ReadCommited 隔离级别，可序列化几乎从不需要，并且是实现死锁的有保证的方法。

第二个问题是为什么序列化会死锁？它由于表扫描而死锁，这表明您没有适当的索引来进行读取和更新。

最后一个问题是您使用 RequiresNew，这在 99% 的情况下都是不正确的。除非您对正在发生的事情有真正深入的了解，并且有充分的理由需要独立事务，否则您应该始终使用 Required 并加入调用者的包围事务。

Answer 2

这并没有涵盖您问题中的所有内容，而是重试的主题。重试事务的想法，无论是否是数据库，都是危险的，如果“幂等”这个词对你来说毫无意义，你不应该阅读这篇文章（坦率地说，我对此也不太了解，但我的管理层有最终决定权，我我去写了关于死锁的重试，我和几个我在这个领域认识的最聪明的人交谈过，他们都给我回复了“糟糕糟糕”，所以我对提交该免责声明感到不舒服。这样做也可以让它变得有趣......，这是我最近写的东西，在抛出和返回之前重试 MySql 死锁指定的次数

使用匿名方法，你只需要有一个可以动态处理方法签名和泛型的接收器返回类型。您还需要一个类似的 void return 类型，只需使用 Action() 对于 MSSQL，我认为它看起来几乎相同，减去 'my'

1. 执行重试的处理程序：

   //

   private T AttemptActionReturnObject（Func 操作）
           {
               var 尝试计数 = 0;
   
               做
               {
                   尝试计数++；
                   尝试
                   {
                       返回动作（）；
                   }
                   捕获（MySqlException 前）
                   {
                       if (attemptCount <= DB_DEADLOCK_RETRY_COUNT)
                       {
                           开关（例如数字）
                           {
                               case 1205: //(ER_LOCK_WAIT_TIMEOUT) 超出锁等待超时
                               case 1213: //(ER_LOCK_DEADLOCK) 尝试获取锁时发现死锁
                                   Thread.Sleep(尝试计数*1000);
                                   休息;
                               默认：
                                   扔;
                           }
                       }
                       别的
                       {
                           扔;
                       }
                   }
               而（真）；
           }
   

2. 使用委托或 lambda 包装您的方法调用

    public int ExecuteNonQuery(MySqlConnection 连接, string commandText, params MySqlParameter[] commandParameters)
   {
       尝试
       {
           return AttemptActionReturnObject( () => MySqlHelper.ExecuteNonQuery(connection, commandText, commandParameters) );
       }
       catch（异常前）
       {
           抛出新的异常（例如ToString（）+“对于SQL语句：”+commandText）；
       }
   }
   

它也可能如下所示：

return AttemptActionReturnObject(delegate { return MySqlHelper.ExecuteNonQuery(connection, commandText, commandParameters); });

Answer 3

当 SQL 检测到死锁时，它会终止一个线程并报告错误。如果您的线程被终止，它会自动回滚任何未提交的事务 - 在您的情况下，是在最近的事务期间已经运行的所有 DatabaseUpdate*() 。

处理这个问题的方法完全取决于您的环境。如果你有像控制表或字符串表之类的东西，它不更新，但经常读取。您可以使用NOLOCK...提示踢和尖叫...当您不担心时间或交易敏感信息时，它实际上非常有用。但是，当您处理易失性或有状态信息时，不能使用 NOLOCK，因为它会导致意外行为。

我使用两种方法来处理死锁。当您检测到故障时，可以直接从头开始重新启动事务。或者您可以在使用变量之前读入它们，然后执行。第二个是一种资源消耗，并且性能显着下降，因此不应该将其用于高容量功能。

Answer 4

我认为不同的数据库服务器对死锁的响应可能不同，但是对于 SQL Server，如果两个事务发生死锁，服务器将选择一个事务作为死锁受害者（错误 1205），并且该事务将回滚。这当然意味着其他交易能够继续进行。

如果您是死锁受害者，则必须重做所有数据库更新，而不仅仅是 update6。

为了回应有关使用 NOLOCK 等提示避免死锁的评论，我强烈建议不要使用它。

死锁是生活中的一个事实。想象一下，两个用户各自向会计系统提交手动日记账分录
第一个条目记入银行帐户和帐户的贷方。应收账款的借方。
第二个条目对 ar & 进行借记。信贷银行。

现在假设两个交易同时进行（这种情况在测试中很少发生）

交易 1 锁定银行账户
交易 2 锁定应收账款账户。
事务 1 尝试锁定应收账款并阻止等待事务 2。
事务 2 尝试锁定银行，并立即自动检测到死锁。
其中一项事务被选为死锁的受害者并被回滚。另一笔交易继续进行，就好像什么也没发生一样。

僵局是一个现实，应对僵局的方法非常简单。 “请挂断电话并重试。”

有关使用 SQL Server 处理死锁的详细信息，请参阅 MSDN