目录(结尾附加项目代码资源地址)
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 提供的子事务屏障，自动处理了补偿操作中的各种情况，用户只需要执行与正向操作完全相反的补偿即可
5. 异常
在事务领域，异常是需要重点考虑的问题，例如宕机失败，进程crash都有可能导致不一致。当我们面对分布式事务，那么分布式中的异常出现更加频繁，对于异常的设计和处理，更是重中之重。
我们将异常分为以下几类：
- 偶发失败： 在微服务领域，由于网络抖动、机器宕机、进程Crash会导致微小比例的请求失败。这类问题的解决方案是重试，第二次进行重试，就能够成功，因此微服务框架或者网关类的产品，都会支持重试，例如配置重试3次，每次间隔2s。DTM的设计对重试非常友好，应当支持幂等的各个接口都已支持幂等，不会发生因为重试导致事务bug的情况
- 故障宕机： 大量公司内部都有复杂的多项业务，这些业务中偶尔有一两个非核心业务故障也是常态。DTM也考虑了这样的情况，在重试方面做了指数退避算法，如果遇见了故障宕机情况，那么指数退避可以避免大量请求不断发往故障应用，避免雪崩。
- 网络乱序： 分布式系统中，网络延时是难以避免的，所以会发生一些乱序的情况，例如转账的例子中，可能发生服务器先收到撤销转账的请求，再收到转账请求。这类的问题是分布式事务中的一个重点难点问题。
业务上的失败与异常是需要做严格区分的，例如前面的余额不足，是业务上的失败，必须回滚，重试毫无意义。分布式事务中，有很多模式的某些阶段，要求最终成功。例如dtm的补偿操作，是要求最终成功的，只要还没成功，就会不断进行重试，直到成功。
6. 异常与子事务屏障
分布式事务之所以难，主要是因为分布式系统中的各个节点都可能发生各种非预期的情况。本文先介绍分布式系统中的异常问题，然后介绍这些问题带给分布式事务的挑战，接下来指出现有各种常见用法的问题，最后给出正确的方案。
6.1 NPC的挑战
分布式系统最大的敌人可能就是NPC了，在这里它是Network Delay, Process Pause, Clock Drift的首字母缩写。我们先看看具体的NPC问题是什么：
- Network Delay，网络延迟。虽然网络在多数情况下工作的还可以，虽然TCP保证传输顺序和不会丢失，但它无法消除网络延迟问题。
- Process Pause，进程暂停。有很多种原因可以导致进程暂停：比如编程语言中的GC（垃圾回收机制）会暂停所有正在运行的线程；再比如，我们有时会暂停云服务器，从而可以在不重启的情况下将云服务器从一台主机迁移到另一台主机。我们无法确定性预测进程暂停的时长，你以为持续几百毫秒已经很长了，但实际上持续数分钟之久进程暂停并不罕见。
- Clock Drift，时钟漂移。现实生活中我们通常认为时间是平稳流逝，单调递增的，但在计算机中不是。计算机使用时钟硬件计时，通常是石英钟，计时精度有限，同时受机器温度影响。为了在一定程度上同步网络上多个机器之间的时间，通常使用NTP协议将本地设备的时间与专门的时间服务器对齐，这样做的一个直接结果是设备的本地时间可能会突然向前或向后跳跃。
分布式事务既然是分布式的系统，自然也有NPC问题。因为没有涉及时间戳，带来的困扰主要是NP。
6.2 现有方案的问题
我们看到开源项目dtm之外，包括各云厂商，各开源项目，他们给出的业务实现建议大多类似如下（这也是大多数用户最容易想到的方案）：
- 空补偿： “针对该问题，在服务设计时，需要允许空补偿，即在没有找到要补偿的业务主键时，返回补偿成功，并将原业务主键记录下来，标记该业务流水已补偿成功。”
- 防悬挂： “需要检查当前业务主键是否已经在空补偿记录下来的业务主键中存在，如果存在则要拒绝执行该笔服务，以免造成数据不一致。”
事实上，NPC里的P和C，以及P和C的组合，有很多种的场景，都可以导致上述竞态情况，就不一一赘述了。
虽然这种情况发生的概率不高，但是在金融领域，一旦涉及金钱账目，那么带来的影响可能是巨大的。
PS：幂等控制如果也采用“先查再改”，也是一样很容易出现类似的问题。解决这一类问题的关键点是要利用唯一索引，“以改代查”来避免竞态条件。
6.3 子事务屏障
在dtm中，首创了子事务屏障技术，使用该技术，能够非常便捷的解决异常问题，极大的降低了分布式事务的使用门槛。
子事务屏障能够达到下面这个效果，看示意图：
所有这些请求，到了子事务屏障后：不正常的请求，会被过滤；正常请求，通过屏障。开发者使用子事务屏障之后，前面所说的各种异常全部被妥善处理，业务开发人员只需要关注实际的业务逻辑，负担大大降低。 子事务屏障提供了方法BranchBarrier.Call，业务开发人员，在busiCall里面编写自己的相关逻辑，调用 BranchBarrier.Call 。 BranchBarrier.Call保证，在空回滚、悬挂等场景下，busiCall不会被调用；在业务被重复调用时，有幂等控制，保证只被提交一次。子事务屏障会管理TCC、SAGA、事务消息等，也可以扩展到其他领域
6.4 原理
子事务屏障技术的原理是，在本地数据库，建立分支操作状态表dtm_barrier，唯一键为全局事务id-分支id-分支操作（try|confirm|cancel）
- 开启本地事务
- 对于当前操作op(try|confirm|cancel)，insert ignore一条数据gid-branchid-op，如果插入不成功，提交事务返回成功（常见的幂等控制方法）
- 如果当前操作是cancel，那么在insert ignore一条数据gid-branchid-try，如果插入成功（注意是成功），则提交事务返回成功
- 调用屏障内的业务逻辑，如果业务返回成功，则提交事务返回成功；如果业务返回失败，则回滚事务返回失败
在此机制下，解决了乱序相关的问题
- 空补偿控制--如果Try没有执行，直接执行了Cancel，那么3中Cancel插入gid-branchid-try会成功，不走屏障内的逻辑，保证了空补偿控制
- 幂等控制--2中任何一个操作都无法重复插入唯一键，保证了不会重复执行
- 防悬挂控制--Try在Cancel之后执行，那么Cancel会在3中插入gid-branchid-try，导致Try在2中不成功，就不执行屏障内的逻辑，保证了防悬挂控制
对于SAGA、二阶段消息，也是类似的机制。
7. 更多高级场景
在实际应用中，还遇见过一些业务场景，需要一些额外的技巧进行处理
7.1 部分第三方操作无法回滚(go语言写了一点，不要在意这些细节，下面开始 .NET)
例如一个订单中的发货，一旦给出了发货指令，那么涉及线下相关操作，那么很难直接回滚。对于涉及这类情况的saga如何处理呢？
我们把一个事务中的操作分为可回滚的操作，以及不可回滚的操作。那么把可回滚的操作放到前面，把不可回滚的操作放在后面执行，那么就可以解决这类问题
saga := dtmcli.NewSaga(DtmServer, shortuuid.New()).
Add(Busi+"/CanRollback1", Busi+"/CanRollback1Revert", req).
Add(Busi+"/CanRollback2", Busi+"/CanRollback2Revert", req).
Add(Busi+"/UnRollback1", "", req).
Add(Busi+"/UnRollback2", "", req).
EnableConcurrent().
AddBranchOrder(2, []int{0, 1}). // 指定step 2，需要在0，1完成后执行
AddBranchOrder(3, []int{0, 1}) // 指定step 3，需要在0，1完成后执行示例中的代码，指定Step 2，3 中的 UnRollback 操作，必须在Step 0，1 完成后执行。
对于不可回滚的操作，DTM的设计建议是，不可回滚的操作在业务上也不允许返回失败。可以这么思考，如果发货的操作返回了失败，那么这个失败的含义是不够清晰的，调用方不知道这个失败是修改了部分数据的失败，还是修改数据前的业务校验失败，因为这个操作不可回滚，所以调用方收到这个失败，是不知道如何正确处理这个错误的。
另外当你的一个全局事务中，如果出现了两个既不可回滚的又可能返回失败的操作，那么到了实际运行中，一个执行成功，一个执行失败，此时执行成功的那个事务无法回滚，那么这个事务的一致性就不可能保证了。
对于发货操作，如果可能在校验数据上可能发生失败，那么将发货操作拆分为发货校验、发货两个服务则会清晰很多，发货校验可回滚，发货不可回滚同时也不会失败。
7.2 超时回滚
saga属于长事务，因此持续的时间跨度很大，可能是100ms到1天，因此saga没有默认的超时时间。dtm支持saga事务单独指定超时时间，到了超时时间，全局事务就会回滚。
saga.TimeoutToFail = 1800在saga事务中，设置超时时间一定要注意，这类事务里不能够包含无法回滚的事务分支，因为超时回滚时，已执行的无法回滚的分支，数据就是错的。
8.0 .NET CORE结合DTM实现Saga(C#启动)
8.1 准备工作(和前两期的注册环节、数据库差不多的操作，看过前两期的小伙伴可跳过8.1阶段)
8.1.1 Nuget引入Dtmcli
<ItemGroup>
<PackageReference Include="Dtmcli" Version="1.4.0" />
</ItemGroup>8.1.2 生成转账数据库(EF_CORE)
//模型
public partial class UserMoney
{
public int id { get; set; }
public int money { get; set; }
public int trading_balance { get; set; }
public int balance { get; set; }
public int trymoney { get; set; }
public string guid { get; set; }
}8.1.3 DbContext
public class DtmDbContext : DbContext
{
public DtmDbContext() { }
public DtmDbContext(DbContextOptions<DtmDbContext> options) : base(opt
最低0.47元/天 解锁文章
5478
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
