事务使用中如何避免误用分布式事务

关注

转载最新推荐文章于 2026-09-06 14:06:31 发布 2.6k 阅读 AI 写同款· GEO 优化 ›

C# 事务- TransactionScop 类如何使用注意：在多数据库或多资源操作的场景下，可能需要确保MSDTC（Microsoft Distributed Transaction Coordinator）服务已经启动并正确配置，因为。可能会提升为分布式事务。此外，根据你的数据库访问模式和.NET版本，你可能需要调整事务的隔离级别或超时设置。命名空间下，用于简化跨多个资源管理器（如数据库连接）的事务处理。以下是一个基本的使用示例，展示了如何使用。来确保一系列操作的原子性，即这些操作要么全部成功，要么全部失败。阅读详情

1：本地事务DbTransaction和分布式事务TransactionScope的区别：

1.1：System.Data.Common.DbTransaction：

本地事务：这个没什么好说了，就是单个事务，每种数据库都有自己的实现，事务的深度内涵可以搜索查看相关的文章，不是本文介绍的重点。

1.2：System.Transactions.TransactionScope：

分布式事务，需要添加引用System.Transactions，同时启用MSDTC分布式事务服务：通常使用方式为：

  
  using (System.Transactions.TransactionScope ts = 
  new System.Transactions.TransactionScope())
  
  {
  
  //
  代码块A
                 
  //
  代码块B
  
                 ts.Complete();
  //
  提交事务
  
  }

分布式事务本质上是引入了第三方裁判，来想办法对多个本地事务监控同时成功或同时失败，这里分享几个知识点：

A：如果代码块里，若存在两个或以上数据库链接DbConnection，则需要启动微软的MSDTC分布式事务服务。

用命令行启动或停止服务：

B：如果代码块里，只有一个数据库链接DbConnection，那么实际上只是本地事务在处理，就算MSDTC分布式事务服务没启动，也不会报错。

C：对于TransactionScope包含的代码块，本质是监控了代码块里数据库链接DbConnection的个数，如果有多个不同的对象，则引入MSDTC当裁判，而实际执行的事务的还是各个本地事务。

D：MSDTC总是不够稳定，我在测试时两个简单的事务一起时，按住F5不停刷新，竟然能把MSSQL服务也给挂了，而用本地事务就算跨库也不会有问题。

所以，不是必须的情况，尽量不要引入分布式事务，应该避免使用TransactionScope来包含事务块的冲动。

2：可以用本地事务解决，避免使用分布式事务场景：

2.1：项目只有一个数据库，这个是最应该避免，多个表间的事务，完全是本地事务可处理的范围：

问题：一个代码块里N个实体类杂交操作，每个实体类带有各种的数据库链接，从而引发了MSDTC。

可以：共用一个DbConnection对象，来避免启用MSDTC。

2.2：项目多个数据库，如果数据库间使用了相同的访问账号和密码，这种情况也可以避免：

每种数据库有自己的解决方式：像MSSQL，跨库处理只要加前缀（dbname..tablename)就可以，因此也使的只使用本地事务就可以处理了。

3：回顾下我以前的项目场景：

3.1：从下图是我08年在中域的项目：有19个数据库，对于数据库链接而言，唯一的不同只有数据库的名称：

进化：能不能只保留一条，其它的通过动态切换数据库名称来改链接字符串？

3.2：那时候，我的架构还是很新手，通过CodeSmith生成了大量的代码文件：

实体类项目，工厂项目，接口项目，数据操作，还有大量的增删改查存储过程，只是为了基础的增删改查而且只针对MSSQL。

随便展开一个项目都会看到大量的文件夹，里面有大量的文件，而这些东东，都是代码生成器的杰作：

19个数据库啊，NN个表，光生成这些基本的增删改查，整个项目就好像高端大气上档次了。

进化：能不能消灭这些大量的文件，简单是我们不断追求的目标。

3.3：这么多数据库，如何跨数据库事务？

对于生成的大量的实体，每个表的操作都是一个新的链接，单库间的事务都必须MSDTC了，更别说19个库间的跨库事务了。

进化：能不能本地事务搞定这些，这是每个ORM可以思考的方向。

4：CYQ.Data 提供的解决方案：

为了消灭上述的那些大量的生成文件，我在后续新的公司写了传统的ORM框架：XQData（这个框架一直没露过面，也只是支持MSSQL，用反射消灭了好多层，只留下实体层）。

对于框架的演进，多数都来源于项目中遇到的问题，或复杂的场景，需要解决或者简化，才有了不断升级的可能，并不是无中生有，因此，一个框架，如果不能不断在在项目中实战，那么很多问题和细节等可能都无法发现，更新也会遥遥无期。

而CYQ.Data的不断升级，说明我一直在奋战在一线的编码生涯中和网友各大项目中的实战反馈中。

下面针对最近的优化调整，演示下CYQ.Data是怎么解决上面提到的几个问题：

4.1：多个数据库的数据库链接切换：

A：先用配置工具生成针对多数据库的枚举文件，和成demo和test两个数据库：

两个数据库就生成两次了。

B：配置一个默认的链接字符串，到Demo数据库：

  <add name=
  "
  Conn
  " connectionString=
  "
  server=.;database=demo;uid=sa;pwd=123456
  "/>
 

C：打印操作Test数据库表的链接字符串：

  using (MAction action = 
  new MAction(TestEnum.Users))
  
             {
  
                 Console.WriteLine(action.ConnectionString);
  
             }

输出：

这里自动切换了数据为名称为新的链接，而我动手脚的地方就是在枚举的名称了。

4.2：本地多数据库跨事务，示例：

  
             AppDebug.OpenDebugInfo = 
 true;
 
             AppDebug.Start();
 
using (MAction action = 
 new MAction(DemoEnum.Users))
 
             {
 
                  action.BeginTransation();//开启事务
 
                  action.Fill(
 12);
 
                 Console.WriteLine(action.ConnectionString);//打印数据库链接
 
                 action.ResetTable(TestEnum.Users);//切换数据库
 
                 Console.WriteLine(action.ConnectionString);//打印数据库链接
 
                 action.Fill(
 12);
 
                 action.EndTransation();
 
             }
 
             Console.WriteLine(AppDebug.Info);//输出所有执行的SQL语句。
 
             AppDebug.Stop();