聊一聊如何用C#轻松完成一个TCC分布式事务

Posted dotNET跨平台

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了聊一聊如何用C#轻松完成一个TCC分布式事务相关的知识,希望对你有一定的参考价值。

背景

银行跨行转账业务是一个典型分布式事务场景,假设 A 需要跨行转账给  B,那么就涉及两个银行的数据,无法通过一个数据库的本地事务保证转账的 ACID ,只能够通过分布式事务来解决。

在  聊一聊如何用C#轻松完成一个SAGA分布式事务 中介绍了借助 DTM 用 SAGA 事务模式解决了上面的银行跨行转账业务。

这一篇我们就来看看如何用 TCC 的事务模式来处理这个问题。

什么是 TCC

TCC是Try、Confirm、Cancel三个词语的缩写,最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。

TCC分为3个阶段

  • Try 阶段:尝试执行,完成所有业务检查(一致性), 预留必需的业务资源(准隔离性)

  • Confirm 阶段:如果所有分支的Try都成功了,则走到Confirm阶段。Confirm真正执行业务,不作任何业务检查,只使用 Try 阶段预留的业务资源

  • Cancel 阶段:如果所有分支的Try有一个失败了,则走到Cancel阶段。Cancel释放 Try 阶段预留的业务资源。

对于前面的跨行转账业务,最简单的做法是,在Try阶段调整余额,在Cancel阶段反向调整余额,Confirm阶段则空操作。这么做带来的问题是,如果A扣款成功,金额转入B失败,最后回滚,把A的余额调整为初始值。在这个过程中如果A发现自己的余额被扣减了,但是收款方B迟迟没有收到余额,那么会对A造成困扰。

更好的做法是,Try阶段冻结A转账的金额,Confirm进行实际的扣款,Cancel进行资金解冻,这样用户在任何一个阶段,看到的数据都是清晰明了的。

下面我们进行一个 TCC 事务的具体开发

前置工作

dotnet add package Dtmcli --version 0.4.0

注:相比 0.3.0,0.4.0 支持了 4 个新的特性,详见 https://github.com/dtm-labs/dtmcli-csharp/releases/tag/v0.4.0

成功的 TCC

先来看一下一个成功完成的 TCC 时序图。

可以看到它的流程和 SAGA 的还是有比较大的区别。

同样的,上图的微服务1,对应我们示例的 OutApi,也就是转钱出去的那个服务。

微服务2,对应我们示例的 InApi,也就是转钱进来的那个服务。

下面我们来编写两个服务的Try/Confirm/Cancel的处理。

OutApi

app.MapPost("/api/TransOutTry", async (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) => 

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    using var db = Db.GeConn();
    await bb.Call(db, async (tx) =>
    
        Console.WriteLine($"用户【req.UserId】转出【req.Amount】Try 操作,bb=bb");
        // tx 参数是事务,可和本地事务一起提交回滚
        await Task.CompletedTask;
    );

    return Results.Ok(TransResponse.BuildSucceedResponse());
);

app.MapPost("/api/TransOutConfirm", async (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) =>

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    using var db = Db.GeConn();
    await bb.Call(db, async (tx) =>
    
        Console.WriteLine($"用户【req.UserId】转出【req.Amount】Confirm操作,bb=bb");
        await Task.CompletedTask;
    );

    return Results.Ok(TransResponse.BuildSucceedResponse());
);

app.MapPost("/api/TransOutCancel", async (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) =>

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    using var db = Db.GeConn();
    await bb.Call(db, async (tx) =>
    
        Console.WriteLine($"用户【req.UserId】转出【req.Amount】Cancel操作,bb=bb");
        await Task.CompletedTask;
    );

    return Results.Ok(TransResponse.BuildSucceedResponse());
);

InApi

app.MapPost("/api/TransInTry", async (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) =>

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    using var db = Db.GeConn();
    await bb.Call(db, async (tx) =>
    
        Console.WriteLine($"用户【req.UserId】转入【req.Amount】Try操作,bb=bb");
        await Task.CompletedTask;
    );

    return Results.Ok(TransResponse.BuildSucceedResponse());
);

app.MapPost("/api/TransInConfirm", async (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) =>

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    using var db = Db.GeConn();
    await bb.Call(db, async (tx) =>
    
        Console.WriteLine($"用户【req.UserId】转入【req.Amount】Confirm操作,bb=bb");
        await Task.CompletedTask;
    );

    return Results.Ok(TransResponse.BuildSucceedResponse());
);

app.MapPost("/api/TransInCancel", async (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) =>

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    using var db = Db.GeConn();
    await bb.Call(db, async (tx) =>
    
        Console.WriteLine($"用户【req.UserId】转入【req.Amount】Cancel操作,bb=bb");
        await Task.CompletedTask;
    );

    return Results.Ok(TransResponse.BuildSucceedResponse());
);

到此各个子事务的处理已经OK了,在上面的代码中,下面这几行是子事务屏障相关代码,只要按照这个方式来调用您的业务逻辑,子事务屏障保证重复请求、悬挂、空补偿情况出现时,您的业务逻辑不会被调用,保证了正常业务的正确进行

var bb = bbFactory.CreateBranchBarrier(context.Request.Query);
await bb.Call(db, async (tx) =>

    // 业务操作...
);

然后准备开启 TCC 事务,进行分支调用

var cts = new CancellationTokenSource();

var gid = await dtmClient.GenGid(cts.Token);

var res = await tccGlobalTransaction.Excecute(gid, async (tcc) =>

    // 用户1 转出30元
    var res1 = await tcc.CallBranch(userOutReq, outApi + "/TransOutTry", outApi + "/TransOutConfirm", outApi + "/TransOutCancel", cts.Token);

    // 用户2 转入30元
    var res2 = await tcc.CallBranch(userInReq, inApi + "/TransInTry", inApi + "/TransInConfirm", inApi + "/TransInCancel", cts.Token);
    
    Console.WriteLine($"case1, branch-out-res= res1 branch-in-res= res2");
, cts.Token);

Console.WriteLine($"case1, gid tcc 提交结果 = res");

到这里,一个完整的 TCC 分布式事务就编写完成了。

需要注意的地方:

  1. 依赖 TccGlobalTransaction ,这个是单例的

  2. tcc 的 CallBranch 方法就是事务分支的调用

搭建好 dtm 的环境后,运行上面的例子,会看到下面的输出。

成功的示例都是相对比较简单的。

下面来看一个 TCC 回滚的例子。

TCC 的回滚

假如银行将金额准备转入用户2时,发现用户2的账户异常,返回失败,会怎么样?我们修改代码,模拟这种情况:

在 InApi 加多一个转入Try失败的处理接口

app.MapPost("/api/TransInTryError", (IBranchBarrierFactory bbFactory, HttpContext context, TransRequest req) =>

    var bb = bbFactory.CreateBranchBarrier(context.Request.Query);

    Console.WriteLine($"用户【req.UserId】转入【req.Amount】Try--失败,bb=bb");

    return Results.Ok(TransResponse.BuildFailureResponse());
);

再来看一下事务失败交互的时序图

这个跟成功的 TCC 差别就在于,当某个子事务返回失败后,后续就回滚全局事务,调用各个子事务的 Cancel 操作,保证全局事务全部回滚。

再调整一下调用方,把转入 Try 操作替换成上面这个返回错误的接口。

var cts = new CancellationTokenSource();

var gid = await dtmClient.GenGid(cts.Token);

var res = await tccGlobalTransaction.Excecute(gid, async (tcc) =>

    var res1 = await tcc.CallBranch(userOutReq, outApi + "/TransOutTry", outApi + "/TransOutConfirm", outApi + "/TransOutCancel", cts.Token);
    var res2 = await tcc.CallBranch(userInReq, inApi + "/TransInTryError", inApi + "/TransInConfirm", inApi + "/TransInCancel", cts.Token);

    Console.WriteLine($"case2, branch-out-res= res1 branch-in-res= res2");
, cts.Token);

Console.WriteLine($"case2, gid tcc 提交结果 = res");

需要注意的是 CallBranch 方法在对应的微服务返回失败后会抛出异常,进而触发全局事务的回滚操作,这个时候 dtm 才会触发 Cancel 的操作。

运行结果如下:

重点看三个地方,

  • 转入的 Cancel 操作并没有执行,因为这里模拟的是转入失败的情况,子事务屏障判定为空补偿了

  • 没有输出分支调用的结果,是因为执行第二个分支的时候没有返回成功的结果

  • 输出的提交结果为空,表明这个事务是失败的,成功的话会返回这个事务的 gid

写在最后

在这篇文章里,通过 2 个简单的例子,完整给出了编写一个 TCC 事务的过程,涵盖了正常成功完成,异常回滚的情况。

希望对研究分布式事务的您有所帮助。

本文示例代码:https://github.com/catcherwong-archive/2022/tree/main/DtmTccDemo

参考资料

  • https://segmentfault.com/a/1190000040331793

  • https://segmentfault.com/a/1190000040396649

  • https://github.com/dtm-labs/dtmcli-csharp

以上是关于聊一聊如何用C#轻松完成一个TCC分布式事务的主要内容,如果未能解决你的问题,请参考以下文章

聊一聊如何用C#轻松完成一个SAGA分布式事务

聊一聊如何用SonarQube管理.NET代码质量

聊一聊如何用SonarQube管理.NET代码质量

聊一聊分布式事务那些事儿

阿里Seata新版本终于解决了TCC模式的幂等悬挂和空回滚问题

阿里 Seata 新版本终于解决了 TCC 模式的幂等悬挂和空回滚问题