转:分布式事务之TCC服务设计和实现注意事项

 由公司微服务培训引起的一丢丢对TCC的好奇

 

 

 原文:https://yq.aliyun.com/articles/609854

 

一、TCC简介

TCC是一种比较成熟的分布式事务解决方案,可用于解决跨库操作的数据一致性问题;

TCC是服务化的两阶段编程模型,其Try、Confirm、Cancel 3个方法均由业务编码实现;

其中Try操作作为一阶段,负责资源的检查和预留,Confirm操作作为二阶段提交操作,执行真正的业务,Cancel是预留资源的取消;

 

 

 

如下图所示,接入TCC前,业务操作只需要一步就能完成,但是在接入TCC之后,需要考虑如何将其分成2阶段完成,把资源的检查和预留放在一阶段的Try操作中进行,把真正的业务操作的执行放在二阶段的Confirm操作中进行;

 

如下图所示,事务协调器在调用TCC服务的一阶段Try操作时,可能会出现因为丢包而导致的网络超时,此时事务协调器会触发二阶段回滚,调用TCC服务的Cancel操作;

TCC服务在未收到Try请求的情况下收到Cancel请求,这种场景被称为空回滚;TCC服务在实现时应当允许空回滚的执行;

 

如下图所示,事务协调器在调用TCC服务的一阶段Try操作时,可能会出现因网络拥堵而导致的超时,此时事务协调器会触发二阶段回滚,调用TCC服务的Cancel操作;在此之后,拥堵在网络上的一阶段Try数据包被TCC服务收到,出现了二阶段Cancel请求比一阶段Try请求先执行的情况;

用户在实现TCC服务时,应当允许空回滚,但是要拒绝执行空回滚之后到来的一阶段Try请求,即防悬挂控制

 

 

 

无论是网络数据包重传,还是异常事务的补偿执行,都会导致TCC服务的Try、Confirm或者Cancel操作被重复执行;用户在实现TCC服务时,需要考虑幂等控制,即Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的;

 

更多了解,请查看原文:https://yq.aliyun.com/articles/609854

 

 TCC 事务应用场景


我们通过用户下单使用余额+红包支付来看一下TCC事务的具体应用。
假设用户下单操作来自3个系统下单系统、资金账户系统、红包账户系统,下单成功需要同时调用资金账户服务和红包服务完成支付
假设购买商品1000元,使用账户红包200元,余额800元,确认支付。
Try操作
tryX 下单系统创建待支付订单
tryY 冻结账户红包200元
tryZ 冻结资金账户800元
Confirm操作
confirmX 订单更新为支付成功
confirmY 扣减账户红包200元
confirmZ 扣减资金账户800元
Cancel操作
cancelX 订单处理异常,资金红包退回,订单支付失败
cancelY 冻结红包失败,账户余额退回,订单支付失败
cancelZ 冻结余额失败,账户红包退回,订单支付失败

 

posted on 2019-03-05 10:48  Ryana  阅读(997)  评论(0编辑  收藏  举报