公众平台网站建设哪家专业,武进网站建设价位,网页界面设计论文,wordpress注册填写密码错误背景 银行跨行转账业务是一个典型分布式事务场景#xff0c;假设 A 需要跨行转账给 B#xff0c;那么就涉及两个银行的数据#xff0c;无法通过一个数据库的本地事务保证转账的 ACID #xff0c;只能够通过分布式事务来解决。在 聊一聊如何用C#轻松完成一个SAGA分布式事务… 背景 银行跨行转账业务是一个典型分布式事务场景假设 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.00.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的处理。OutApiapp.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());
});InApiapp.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 分布式事务就编写完成了。需要注意的地方依赖 TccGlobalTransaction 这个是单例的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/1190000040331793https://segmentfault.com/a/1190000040396649https://github.com/dtm-labs/dtmcli-csharp
