用Python轻松完成一个分布式事务TCC,保姆级教程

用Python轻松完成一个分布式事务TCC,保姆级教程

作者:佚名 2021-10-25 10:33:29

开发

前端

分布式 分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。

 

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

分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。在上述转账的业务中,用户A-100操作和用户B+100操作不是位于同一个节点上。本质上来说,分布式事务就是为了保证在分布式场景下,数据操作的正确执行。

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

TCC组成

TCC分为3个阶段

  • Try 阶段:尝试执行,完成所有业务检查(一致性), 预留必须业务资源(准隔离性)
  • Confirm 阶段:如果所有分支的Try都成功了,则走到Confirm阶段。Confirm真正执行业务,不作任何业务检查,只使用 Try 阶段预留的业务资源
  • Cancel 阶段:如果所有分支的Try有一个失败了,则走到Cancel阶段。Cancel释放 Try 阶段预留的业务资源。

TCC分布式事务里,有3个角色,与经典的XA分布式事务一样:

  • AP/应用程序,发起全局事务,定义全局事务包含哪些事务分支
  • RM/资源管理器,负责分支事务各项资源的管理
  • TM/事务管理器,负责协调全局事务的正确执行,包括Confirm,Cancel的执行,并处理网络异常

如果我们要进行一个类似于银行跨行转账的业务,转出(TransOut)和转入(TransIn)分别在不同的微服务里,一个成功完成的TCC事务典型的时序图如下:

TCC实践

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

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

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

目前可用于TCC的开源框架,主要为Java语言,其中以seata为代表。我们的例子采用Python语言,使用的分布式事务框架为https://github.com/yedf/dtm,它对分布式事务的支持非常优雅。下面来详细讲解TCC的组成

我们首先创建两张表,一张是用户余额表,一张是冻结资金表,建表语句如下:

  1. CREATE TABLE dtm_busi.`user_account` ( 
  2.   `id` int(11) AUTO_INCREMENT PRIMARY KEY, 
  3.   `user_id` int(11) not NULL UNIQUE , 
  4.   `balance` decimal(10,2) NOT NULL DEFAULT '0.00'
  5.   `create_time` datetime DEFAULT now(), 
  6.   `update_time` datetime DEFAULT now() 
  7. ); 
  8.  
  9. CREATE TABLE dtm_busi.`user_account_trading` ( 
  10.   `id` int(11) AUTO_INCREMENT PRIMARY KEY, 
  11.   `user_id` int(11) not NULL UNIQUE , 
  12.   `trading_balance` decimal(10,2) NOT NULL DEFAULT '0.00'
  13.   `create_time` datetime DEFAULT now(), 
  14.   `update_time` datetime DEFAULT now() 
  15. ); 

trading表中,trading_balance记录正在交易的金额。

我们先编写核心代码,冻结/解冻资金操作,会检查约束balance+trading_balance >= 0,如果约束不成立,执行失败

  1. def tcc_adjust_trading(cursor, uid, amount): 
  2.   affected = utils.sqlexec(cursor, "update dtm_busi.user_account_trading set trading_balance=trading_balance + %d where user_id=%d and trading_balance + %d + (select balance from dtm_busi.user_account where id=%d) >= 0" % (amount, uid, amount, uid)) 
  3.   if affected == 0
  4.     raise Exception("update error, maybe balance not enough"

然后是调整余额

  1. def tcc_adjust_balance(cursor, uid, amount): 
  2.   utils.sqlexec(cursor, "update dtm_busi.user_account_trading set trading_balance = trading_balance+ %d where user_id=%d" %( -amount, uid)) 
  3.   utils.sqlexec(cursor, "update dtm_busi.user_account set balance=balance+%d where user_id=%d" %(amount, uid)) 

下面我们来编写具体的Try/Confirm/Cancel的处理函数

  1. @app.post("/api/TransOutTry"
  2. def trans_out_try(): 
  3.   # 事务以及异常处理 
  4.   tcc_adjust_trading(c, out_uid, -30
  5.   return {"dtm_result""SUCCESS"
  6.  
  7. @app.post("/api/TransOutConfirm"
  8. def trans_out_confirm(): 
  9.   # 事务以及异常处理 
  10.   tcc_adjust_balance(c, out_uid, -30
  11.   return {"dtm_result""SUCCESS"
  12.  
  13. @app.post("/api/TransOutCancel"
  14. def trans_out_cancel(): 
  15.   # 事务以及异常处理 
  16.   tcc_adjust_trading(c, out_uid, 30
  17.   return {"dtm_result""SUCCESS"
  18.  
  19. @app.post("/api/TransInTry"
  20. def trans_in_try(): 
  21.   # 事务以及异常处理 
  22.   tcc_adjust_trading(c, in_uid, 30
  23.   return {"dtm_result""SUCCESS"
  24.  
  25. @app.post("/api/TransInConfirm"
  26. def trans_in_confirm(): 
  27.   # 事务以及异常处理 
  28.   tcc_adjust_balance(c, in_uid, 30
  29.   return {"dtm_result""SUCCESS"
  30.  
  31. @app.post("/api/TransInCancel"
  32. def trans_in_cancel(): 
  33.   # 事务以及异常处理 
  34.   tcc_adjust_trading(c, in_uid, -30
  35.   return {"dtm_result""SUCCESS"

到此各个子事务的处理函数已经OK了,然后是开启TCC事务,进行分支调用

  1. @app.get("/api/fireTcc"
  2. def fire_tcc(): 
  3.     # 发起tcc事务 
  4.     gid = tcc.tcc_global_transaction(dtm, utils.gen_gid(dtm), tcc_trans) 
  5.     return {"gid": gid} 
  6.  
  7. # tcc事务的具体处理 
  8. def tcc_trans(t): 
  9.     req = {"amount"30} # 业务请求的负荷 
  10.     # 调用转出服务的Try|Confirm|Cancel 
  11.     t.call_branch(req, svc + "/TransOutTry", svc + "/TransOutConfirm", svc + "/TransOutCancel"
  12.     # 调用转入服务的Try|Confirm|Cancel 
  13.     t.call_branch(req, svc + "/TransInTry", svc + "/TransInConfirm", svc + "/TransInCancel"

至此,一个完整的TCC分布式事务编写完成。

如果您想要完整运行一个成功的示例,那么按照dtmcli-py-sample项目的说明tcc的例子即可

TCC的回滚

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

  1. @app.post("/api/TransInTry"
  2. def trans_in_try(): 
  3.   # 事务以及异常处理 
  4.   tcc_adjust_trading(c, in_uid, 30
  5.   return {"dtm_result""FAILURE"

这是事务失败交互的时序图

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

TCC网络异常

TCC在整个全局事务的过程中,可能发生各类网络异常情况,典型的是空回滚、幂等、悬挂,由于TCC的异常情况,和SAGA、可靠消息等事务模式有相近的地方,因此我们把所有异常的解决方案统统放在这篇文章分布式事务最经典的七种解决方案的异常处理章节进行讲解

小结

在这篇文章里,我们介绍了TCC的理论知识,也通过一个例子,完整给出了编写一个TCC事务的过程,涵盖了正常成功完成,以及成功回滚的情况。相信读者通过这边文章,对TCC已经有了深入的理解。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/308053.html<

(0)
管理的头像管理
上一篇2025-05-27 10:01
下一篇 2025-05-27 10:02

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注