.NET CORE 分布式事务(一) DTM实现二阶段提交

已于 2024-04-24 09:34:28 修改
阅读量2k 收藏 15
点赞数 29
文章标签： .netcore 分布式 架构 微服务
于 2024-03-21 14:17:01 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/m0_59178355/article/details/136905464
版权
本文详细介绍了.DNET CORE中使用DTM实现分布式事务的二阶段提交，包括分布式事务的基本概念、目标和挑战，重点阐述了二阶段消息的执行流程、成功和异常情况的处理，并给出了具体的.NET CORE代码实现，包括Docker部署和Kubernetes部署的指导。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

目录

引言：

1. 分布式事务的基本概念

2. 分布式事务的目标

3. 分布式事务面临的挑战

4. 分布式事务的常见解决方案

5. DTM是什么

6. 二阶段消息

6.1 概述

6.2 执行流程

6.2.1 成功流程

6.2.2 提交后宕机流程

6.2.3 提交前宕机流程

6.2.4 二阶段消息的应用

6.2.5 回查原理剖析

7. .NET CORE结合DTM实现二阶段信息提交

7.1 Docker部署

7.2 docker-compose启动

7.3 Kubernetes部署

7.4 代码实现

7.4.1 引入Nuget包

7.4.2 生成转账数据库(EF_CORE)

7.4.3 数据库持久化

7.4.5 appsettings.json

7.4.6 Program.cs

7.4.7 本地事务API控制器

7.4.8 转账服务事务API控制器

总结：

引言：

分布式事务是在分布式系统中处理跨越多个数据库或服务的一组操作的方式。它确保在整个操作链路中，所有参与服务要么一起成功执行，要么一起回滚，以保持数据的一致性和完整性。以下是关于分布式事务的详细介绍： (此系列将针对DTM中的TCC、Sage、二阶段信息，以及.NET CORE 中的NCC_CAP最终一致性分布式事务，全面讲解，请持续关注。)

1. 分布式事务的基本概念

  • 事务参与者：在分布式事务中，每个参与到事务中的数据库或服务都被称为事务参与者。
  • 事务协调者：通常是应用程序服务，负责协调各个事务参与者，确保它们遵循相同的事务逻辑。
  • 资源管理器 (RM)：资源管理器通常与事务参与者相同，负责管理和更新事务涉及的数据。
  • 事务管理器 (TM)：作为全局协调者，事务管理器跟踪事务的状态，决定何时提交或回滚。

2. 分布式事务的目标

  • ACID 属性：分布式事务旨在实现传统的数据库事务的四大特性：
    • 原子性 (Atomicity)：事务作为一个单元执行，要么全部完成，要么全部不完成。
    • 一致性 (Consistency)：事务完成后，系统处于一致状态，满足所有的约束条件。
    • 隔离性 (Isolation)：并发事务之间相互独立，不会相互影响。
    • 持久性 (Durability)：一旦事务提交，其更改将永久保留。

3. 分布式事务面临的挑战

  • CAP 理论：分布式系统面临选择一致性 (C)，可用性 (A)，或分区容错性 (P) 的困境，无法同时满足三者。
  • 隔离级别：各种隔离级别如读未提交、读已提交、可重复读和串行化，对应不同的并发控制策略，可能导致脏读、不可重复读和幻读等问题。

4. 分布式事务的常见解决方案

  1. 两阶段提交 (2PC)：TM先询问所有RM是否准备好提交，得到肯定回复后，再统一提交或回滚。缺点是可能导致阻塞，并且不能保证强一致性。
  2. 补偿事务 (Saga)：长事务分为一系列短事务，每个都有一个对应的补偿操作，如果某个步骤出错，可以通过执行补偿操作回滚整个事务。
  3. 分布式事务协调器 (如 TCC、Seata)：通过提供专门的事务协调组件来协助服务间的事务管理。
  4. 最终一致性：不是立即一致，但在一段延迟后确保所有数据源达到一致状态。
  5. 基于消息队列的事务：事务消息在消息队列中等待确认，直到所有相关的服务都成功处理了消息。

5. DTM是什么

DTM是一款开源的分布式事务管理器，解决跨数据库、跨服务、跨语言栈更新数据的一致性问题。

通俗一点说，DTM提供跨服务事务能力，一组服务要么全部成功，要么全部回滚，避免只更新了一部分数据产生的一致性问题。

6. 二阶段消息

6.1 概述

DTM提出的二阶段消息，可以完美替代现有的事务消息或本地消息表架构。无论从复杂度、便利性、性能，还是代码量，新架构都完胜现有架构方案，是这个领域的革命性架构。

二阶段消息是dtm首创的事务模式，用于替换本地事务表和事务消息这两种现有的方案。它能够保证本地事务的提交和全局事务提交是“原子的”，适合解决不需要回滚的分布式事务场景。下面我们来看看二阶段消息，如何解决这个业务场景的问题。

6.2 执行流程

6.2.1 成功流程

一般情况下，时序图中的5个步骤会正常完成，整个业务按照预期进行，全局事务完成。这里面有个新的内容需要解释一下，就是msg的提交是按照两个阶段发起的，第一阶段调用Prepare，第二阶段调用Commit，DTM收到Prepare调用后，不会调用分支事务，而是等待后续的Submit。只有收到了Submit，开始分支调用，最终完成全局事务。

6.2.2 提交后宕机流程

 

 如果在本地事务提交之后，在发送Submit前，出现了进程Crash或者机器宕机会怎么样？这个时候DTM会在一定超时时间之后，取出只Prepare但未Submit的msg事务，调用msg事务指定的回查服务。

6.2.3 提交前宕机流程

 

如果在DTM收到Prepare调用后，AP在事务提交前，遇见故障宕机，那么数据库会检测到AP的连接断开，自动回滚本地事务。

后续DTM轮询取出已经超时的，只Prepare但没有Submit的全局事务，进行回查。回查服务发现本地事务已回滚，返回结果给DTM。DTM收到已回滚的结果后，将全局事务标记为失败，并结束该全局事务。

6.2.4 二阶段消息的应用

二阶段消息能够大幅降低消息最终一致性解决方案的难度，已获得广泛的应用，下面是两个典型的应用。

  • 秒杀系统：该架构下单机可以轻松扛住上万个订单请求，并且保证库存数量和订单数量准确匹配
  • 缓存一致性：通过二阶段消息，可以轻松保证DB与缓存的一致性，大大优于队列或订阅binlog的方案

6.2.5 回查原理剖析

前面的时序图中，以及接口中都出现了回查服务，在二阶段消息中，是复制粘贴代码自动处理的，而RocketMQ的事务消息，则是手动处理的。那么自动处理的原理是什么？

要进行回查，首先要在业务数据库实例中，建立一张独立的表，里面保存全局事务id。在处理业务事务时，会把gid写入到这张表。

当我们用gid回查时，如果能够在表中查到gid，那么说明本地事务已提交，这样就可以返回DTM，告知本地事务已提交。

当我们用gid回查时，没有在表中查到gid，那么说明本地事务未提交，此时可能的结果是两个，一是事务还在进行中，二是事务已回滚。我查了许多关于RocketMQ的资料，未找到有效的解决方案。搜到所有解决方案是，如果未查到结果，那么什么都不做，等待下一次回查，如果2分钟或者更久的回查，一直都是查不到的，那么认为本地事务已回滚。

上述这种方案有很大的问题：

  • 两分钟还查不到gid，并不能认为本地事务已回滚，极端情况下，可能发生数据库故障（例如进程或磁盘卡住了ÿ
最低0.47元/天 解锁文章
.NET CORE 分布式事务(三) DTM实现Saga及高并发下的解决方案
m0_59178355的博客
03-26 2531
可以这么思考，如果发货的操作返回了失败，那么这个失败的含义是不够清晰的，调用方不知道这个失败是修改了部分数据的失败，还是修改数据前的业务校验失败，因为这个操作不可回滚，所以调用方收到这个失败，是不知道如何正确处理这个错误的。例如dtm的补偿操作，是要求最终成功的，只要还没成功，就会不断进行重试，直到成功。另外当你的一个全局事务中，如果出现了两个既不可回滚的又可能返回失败的操作，那么到了实际运行中，一个执行成功，一个执行失败，此时执行成功的那个事务无法回滚，那么这个事务的一致性就不可能保证了。
.NET Core 事件总线,分布式事务解决方案：CAP
weixin_33894992的博客
07-21 411
背景 相信前面几篇关于微服务的文章也介绍了那么多了，在构建微服务的过程中确实需要这么一个东西，即便不是在构建微服务，那么在构建分布式应用的过程中也会遇到分布式事务的问题，那么 CAP 就是在这样的背景下诞生的。 最初打算做这个东西是在去年（2016）年底，最初是为了解决分布式系统中的分布式事务的问题，然后当时有了一个大概的概念轮廓，当时我对于前面两篇文章中关于异步消息和微服务之间通讯还不是太了解，...
分布式事务解决方案以及 .Net Core 下的实现（上）
10年职场两茫茫，35岁凄凉奈若何
10-31 204
分布式事务解决方案以及 .Net Core 下的实现（上）
.NET CORE 分布式事务(二) DTM实现TCC
m0_59178355的博客
03-25 1635
紧接上一期.NET CORE 分布式事务(一) DTM实现二阶段提交(
DTM分布式事务
qq_45366447的博客
01-08 1731
DTM，Distributed Transaction Manager， 其是一个分布式事务管理器，解决跨数据库、跨服务、跨语言更新数据的一致性问题。 ​ DTM提供了Saga、TCC、XA和二阶段消息模式以满足不同应用场景的需求，同时首创的**子事务屏障**技术有效解决`幂等`、`悬挂`和`空补偿`等异常问题。 ​ DTM的优点： - 提供简单易用的接口，拆分具体业务接入分布式事务 - 支持多语言栈 - 核心技术**子事务屏蔽**，降低处理子事务乱的难度
.NET CORE 分布式事务(四) CAP实现最终一致性
m0_59178355的博客
03-30 2486
在分布式系统中，事务管理是确保数据一致性和系统稳定性的关键技术。传统的集中式事务处理模型（如两阶段提交协议）在分布式环境中面临诸多挑战，包括性能瓶颈、单点故障和扩展性问题。为了解决这些问题，最终一致性模型被提出并广泛应用于分布式事务处理中。最终一致性（Eventual Consistency）是一种分布式系统的数据一致性模型，它不要求数据在每个时刻都保持一致，而是允许数据在短时间内不一致，但保证在一定时间后，所有节点上的数据会达到一致状态。这种模型降低了对即时一致性的要求，从而提高了系统的可用性和扩展性。
.NET Core 中实现分布式事务的几种方案
polsnet的专栏
04-01 2312
在这种方案中，分布式事务的实现基于消息队列的支持，如 RabbitMQ、Kafka 等。在这种方案中，使用分布式事务协调器来协调不同数据库或服务之间的事务，确保所有操作的原子性和一致性。在 .NET Core 中，可以使用开源的分布式事务协调器 Seata 或 NServiceBus 来实现分布式事务的协调。所以，实现分布式事务是一个复杂的过程，需要综合考虑多个方面的因素。不同的方案有其优缺点和适用场景，需要根据实际需求选择合适的方案，并注意方案的实现细节和注意事项，以确保分布式事务的可靠性和一致性。
.netcore 分布式事务CAP2.6 快速入门
zhanglong_longlong的专栏
12-14 292
CAP介绍： CAP是一个用来解决微服务或者分布式系统中分布式事务问题的一个开源项目解决方案。可以解决跨服务器的数据一致性问题。一个简单的列子，如：订单系统创建订单后需要通知邮件通知用户下单成功，解决方案有下面几种： 1：创建订单时同步调用邮件发送，邮件发送失败则整个订单创建失败，这样保证了一致性，但性能和可用性有非常大的问题。或者不管邮件发送状态，失败了就算了，这样用户就可能收不到通知邮件了。 2：创建订单时通过消息队列推送一个订单创建成功的事件，另外创建一个服务来监听消费此事件，并执行...
.NET分布式事务处理
weixin_30598225的博客
06-12 185
　　在进行数据持久化的时候，我们会经常用到事务处理。一般情况下，ADO.NET中的事务处理就能够满足我们的需要，但是，ADO.NET中的事务不能同事对多个数据库连接进行原子性的操作；如果在你的业务环境中存在多个数据库、文件写入等操作，同时需要保证数据完整性和一致性的时候，你可以考虑使用.NET提供的分布式事务处理。 　　使用分布式事务处理，需要Windows系统的支持，所以，我们需要将系统的MS...
.net core with 微服务 - 分布式事务 - tcc 事务
极客神殿
05-17 481
上一次我们讲解了分布式事务的 2PC、3PC 。那么这次我们来理一下 TCC 事务。本次还是讲解 TCC 的原理跟 .NET 其实没有关系。 TCC Try 准备阶段，尝试执行业务 Confirm 完成业务 Cancel 回滚准备阶段的业务 TCC 事务其实是 2PC 的一个扩展。上一次我们说了 2PC ，在二阶段进行事务提交。因为 2PC 基本上是利用数据库的 事务能力进行 commit ，其实这里还有可能出现一种 rollback 情况。 TCC 就是把 2PC 的二阶段细化了，拆分成了 Confi
.NET简谈事务、分布式事务处理
02-08
.NET简谈事务、分布式事务处理 ,DTC应用
dtm分布式事务
走向CTO的路上...
05-16 766
相对于传统的数据库事务，DTM提供了更强大和灵活的分布式事务管理能力。分布式事务支持：DTM提供了对分布式事务的全面支持。DTM（Distributed Transaction Manager）是一种分布式事务管理器，用于处理跨多个服务的分布式事务。范围：传统的数据库事务是在单个数据库内进行的，而DTM可以跨多个服务进行事务操作。多数据库支持：DTM可以支持不同类型的数据库，甚至可以支持不同的数据库引擎。异步补偿：DTM还支持异步补偿机制，可以在事务失败或异常的情况下执行事务的回滚或补偿操作。
.net Core 分布式事务之CAP
小枪 bolg ---hello，wrold
12-28 5672
.netCore分布式事务
【学习笔记】DTM分布式事务
Left_Zzzz的博客
10-13 1068
分布式事务是什么 **本文的分布式事务指的是DTM下的分布式事务。** 分布式事务有两类，这里指的是跨数据库、跨服务的分布式事务。 分布式事务指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。
Net Core 事务
weixin_48786842的博客
06-07 353
NET Core 事务
.net core 下的分布式事务锁
dotNET跨平台
07-10 1658
系统分布式锁的用法公司框架新增功能分布式锁：锁的性能之王：缓存 > Zookeeper >= 数据库锁的实现实现原理：核心采用StackExchange.Redis的LockT...
.net中的分布式事务
blog之antyi
10-15 1481
NET Framework 类库TransactionScope 类注意：此类在 .NET Framework 2.0 版中是新增的。 使代码块成为事务性代码。无法继承此类。 命名空间:System.Transactions程序集:System.Transactions（在 system.transactions.dll 中） 语法 Visual Basic（声明） Public
.net abp框架学习，分布式事务实现，具体示例代码
最新发布
03-30
<think>好的，我现在需要处理用户关于ABP框架学习，特别是分布式事务实现的请求，并提供示例代码。首先，我需要回顾一下ABP框架的基本概念，以及它如何处理分布式事务。ABP框架是基于领域驱动设计（DDD）和分层架构的，所以可能需要涉及到应用层、领域层和基础设施层的代码结构。 用户要求具体示例代码，所以我得确保提供的代码符合ABP的结构，比如使用仓储模式、工作单元（UnitOfWork）等。分布式事务的实现通常涉及跨服务或跨数据库的事务管理，常见解决方案有Saga模式、使用CAP定理实现最终一致性，或者利用分布式事务协调器如DTM或.NET的TransactionScope结合DTC。 ABP框架本身可能没有内置的分布式事务处理，但可以集成其他库或模式。例如，使用CAP库来实现事件总线与事务消息表，保证本地事务和消息发布的原子性。另外，Saga模式需要编写补偿逻辑，处理失败情况下的回滚。 接下来，我需要考虑用户可能的开发环境，比如是否使用Entity Framework Core，是否已经配置了消息队列（如RabbitMQ）或事件总线。示例代码可能需要展示如何在应用服务方法中开启事务，发布集成事件，并处理异常回滚。 我需要确保示例代码的正确性，比如正确使用ABP的UnitOfWork特性，仓储的异步方法，以及异常处理。同时，要提醒用户注意点，比如DTC的配置、CAP库的集成步骤，以及Saga模式中补偿事务的实现。 另外，用户可能需要了解分布式事务的不同实现方式的优缺点，比如最终一致性 vs 强一致性，以及如何根据业务需求选择合适的方法。所以，在回答中需要简要比较这些方法，并说明适用场景。 最后，整理结构，先介绍ABP框架处理分布式事务的常见方法，然后分别给出CAP和Saga的示例代码，并解释关键部分。确保代码用$$...$$包裹，行内公式用$...$，但可能在这个问题中公式较少，不过如果有数学表达式的话需要注意格式。现在需要检查是否有遗漏的点，比如事务的隔离级别，或者ABP框架的特定扩展点，如自定义拦截器等。 总结步骤： 1. 介绍ABP框架处理分布式事务的常见方法。 2. 分点讲解CAP库和Saga模式的实现。 3. 提供每个方法的示例代码，并解释关键部分。 4. 提醒注意事项和配置步骤。 5. 确保代码格式正确，符合用户的系统级指令。</think>以下是关于ABP框架分布式事务实现的逐步说明及示例代码： --- ### 一、ABP框架分布式事务实现方案 ABP框架中常见的分布式事务实现方式： 1. **最终一致性 + 事件总线**（如CAP库） 2. **Saga模式**（手动补偿事务） 3. **DTC（分布式事务协调器）**（需基础设施支持） --- ### 二、方案1：CAP库实现（推荐） #### 1. 安装CAP ```bash dotnet add package DotNetCore.CAP dotnet add package DotNetCore.CAP.EntityFrameworkCore ``` #### 2. 配置CAP（Startup.cs） ```csharp services.AddCap(x => { x.UseEntityFramework<MyDbContext>(); // 使用EF Core事务 x.UseRabbitMQ("localhost"); // 消息队列 x.UseDashboard(); // 监控面板 }); ``` #### 3. 示例代码 ```csharp public class OrderAppService : ApplicationService { private readonly IRepository<Order> _orderRepository; private readonly ICapPublisher _capPublisher; public OrderAppService(IRepository<Order> orderRepository, ICapPublisher capPublisher) { _orderRepository = orderRepository; _capPublisher = capPublisher; } [UnitOfWork] // ABP工作单元 public async Task CreateOrder(OrderCreateDto input) { // 1. 本地事务：创建订单 var order = new Order(input.ProductId, input.Amount); await _orderRepository.InsertAsync(order); // 2. 发布集成事件（与本地事务原子性） await _capPublisher.PublishAsync("OrderCreated", new OrderCreatedEvent { OrderId = order.Id, ProductId = input.ProductId }); // 3. 提交事务时，CAP自动将消息写入数据库 } } // 订阅事件的服务 public class InventoryService : ICapSubscribe { [CapSubscribe("OrderCreated")] public async Task ReduceStock(OrderCreatedEvent @event) { // 扣减库存逻辑 // 若失败，CAP会自动重试 } } ``` --- ### 三、方案2：Saga模式实现 #### 1. Saga协调器示例 ```csharp public class OrderSaga : Saga<OrderSagaData>, IAmStartedByMessages<PlaceOrderCommand>, IHandleMessages<InventoryReservedEvent>, IHandleMessages<PaymentFailedEvent> { public async Task Handle(PlaceOrderCommand message, IMessageHandlerContext context) { // 1. 创建订单 await _orderRepository.InsertAsync(new Order(...)); // 2. 发送预留库存命令 await context.Send(new ReserveInventoryCommand { ProductId = message.ProductId }); } public async Task Handle(InventoryReservedEvent message, IMessageHandlerContext context) { // 3. 发起支付 await context.Send(new ProcessPaymentCommand { OrderId = Data.OrderId }); } public async Task Handle(PaymentFailedEvent message, IMessageHandlerContext context) { // 4. 补偿操作：释放库存 await context.Send(new ReleaseInventoryCommand { ProductId = Data.ProductId }); await _orderRepository.DeleteAsync(Data.OrderId); } } ``` --- ### 四、关键注意事项 1. **CAP方案需配置消息队列**（如RabbitMQ/Kafka） 2. **Saga需手动编写补偿逻辑** 3. **事务隔离级别**需根据业务调整 4. ABP的`[UnitOfWork]`特性默认对数据库连接生效 --- ### 五、ABP扩展建议 - 使用`Volo.Abp.EventBus.Distributed`集成事件 - 结合`Volo.Abp.DistributedLocking`处理并发 - 监控事务状态：集成`CAP Dashboard`或`Saga跟踪工具` 两种方案均能实现分布式事务，建议优先选择CAP方案简化开发，复杂场景使用Saga模式。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值