目录(结尾附加项目代码资源地址)
7.1 部分第三方操作无法回滚(go语言写了一点，不要在意这些细节，下面开始 .NET)
8.0 .NET CORE结合DTM实现Saga(C#启动)
8.1 准备工作(和前两期的注册环节、数据库差不多的操作，看过前两期的小伙伴可跳过8.1阶段)
引言：
紧接前两期 .NET CORE 分布式事务(一) DTM实现二阶段提交(.NET CORE 分布式事务(一) DTM实现二阶段提交-CSDN博客) .NET CORE 分布式事务(二) DTM实现TCC(.NET CORE 分布式事务(二) DTM实现TCC-CSDN博客) 本期讲解Saga分布式事务，并探讨如何在高并发下使用Saga分布式事务。
1. SAGA事务模式
SAGA事务模式是DTM中最常用的模式，主要是因为SAGA模式简单易用，工作量少，并且能够解决绝大部分业务的需求。SAGA最初出现在1987年Hector Garcaa-Molrna & Kenneth Salem发表的论文SAGAS里。其核心思想是将长事务拆分为多个短事务，由Saga事务协调器协调，如果每个短事务都成功提交完成，那么全局事务就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
2. 拆分为子事务
例如我们要进行一个类似于银行跨行转账的业务，将A中的30元转给B，根据Saga事务的原理，我们将整个全局事务，切分为以下服务：
- 转出（TransOut）服务，这里转出将会进行操作A-30
- 转出补偿（TransOutCompensate）服务，回滚上面的转出操作，即A+30
- 转入（TransIn）服务，转入将会进行B+30
- 转入补偿（TransInCompensate）服务，回滚上面的转入操作，即B-30
整个SAGA事务的逻辑是：
执行转出成功=>执行转入成功=>全局事务完成
如果在中间发生错误，例如转入B发生错误，则会调用已执行分支的补偿操作，即：
执行转出成功=>执行转入失败=>执行转入补偿成功=>执行转出补偿成功=>全局事务回滚完成
下面我们看一个成功完成的SAGA事务典型的时序图：
在这个图中，我们的全局事务发起人，将整个全局事务的编排信息，包括每个步骤的正向操作和反向补偿操作定义好之后，提交给服务器，服务器就会按步骤执行前面SAGA的逻辑。
3. 失败回滚
如果有正向操作失败，例如账户余额不足或者账户被冻结，那么dtm会调用各分支的补偿操作，进行回滚，最后事务成功回滚。失败的时序图如下：
补偿执行顺序：
dtm的SAGA事务在1.10.0及之前，补偿操作是并发执行的，1.10.1之后，是根据用户指定的分支顺序，进行回滚的。
如果是普通SAGA，没有打开并发选项，那么SAGA事务的补偿分支是完全按照正向分支的反向顺序进行补偿的。
如果是并发SAGA，补偿分支也会并发执行，补偿分支的执行顺序与指定的正向分支顺序相反。假如并发SAGA指定A分支之后才能执行B，那么进行并发补偿时，DTM保证A的补偿操作在B的补偿操作之后执行
4. 如何做补偿
当SAGA对分支A进行失败补偿时，A的正向操作可能1. 已执行；2. 未执行；3. 甚至有可能处于执行中，最终执行成功或者失败是未知的。那么对A进行补偿时，要妥善处理好这三种情况，难度很大。
dtm提供了子事务屏障技术，自动处理上述三种情况，开发人员只需要编写好针对1的补偿操作情况即可，相关工作大幅简化，详细原理，参见下面的异常章节。
4.1 失败的分支是否需要补偿
dtm 常被问到的一个问题是，TransIn返回失败，那么这个时候是否还需要调用TransIn的补偿操作？DTM 的做法是，统一进行一次调用，这种的设计考虑点如下：
- XA, TCC 等事务模式是必须要的，SAGA 为了保持简单和统一，设计为总是调用补偿
- DTM 支持单服务多数据源，可能出现数据源1成功，数据源2失败，这种情况下，需要确保补偿被调用，数据源1的补偿被执行
- DTM 提供的子事务屏障，自动处理了补偿操作中的各种情况&#
最低0.47元/天 解锁文章
399
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
