怎样实现一个支持TCC事务的业务服务?

支付宝的架构师在InfoQ上分享过SOA架构下的事务处理经验, 其中提到TCC模式(Try-Confirm-Cancel), Try操作要求业务系统能够做完所有的校验以及为事务操作预留资源来实现隔离性,但是在复杂的业务逻辑下, 可能涉及到大片的数据要预留, 不知道怎么做才好。 希望做过的同学能够指点一下。 InfoQ上的链接 infoq.com/cn/interviews
关注者
78
被浏览
10889

4 个回答

TCC是分布式事务实现的一种方式
  1. TRYING 阶段主要是对业务系统做检测及资源预留
  2. CONFIRMING 阶段主要是对业务系统做确认提交,TRYING阶段执行成功并开始执行CONFIRMING阶段时,默认CONFIRMING阶段是不会出错的。即:只要TRYING成功,CONFIRMING一定成功。
  3. CANCELING 阶段主要是在业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放
  4. 而幂等性则是指业务方法调用一次与调用多次的执行返回结果是一样的。
举个支付项目的例子:
支付系统接收到会员的支付请求后,需要扣减会员账户余额、增加会员积分(暂时假设需要同步实现)增加商户账户余额
再假设:会员系统、商户系统、积分系统是独立的三个子系统,无法通过传统的事务方式进行处理。
  1. TRYING阶段:我们需要做的就是会员资金账户的资金预留,即:冻结会员账户的金额(订单金额)
  2. CONFIRMING阶段:我们需要做的就是会员积分账户增加积分余额,商户账户增加账户余额
  3. CANCELING阶段:该阶段需要执行的就是解冻释放我们扣减的会员余额
以上所有的操作需要满足幂等性,幂等性的实现方式可以是:
1、通过唯一键值做处理,即每次调用的时候传入唯一键值,通过唯一键值判断业务是否被操作,如果已被操作,则不再重复操作
2、通过状态机处理,给业务数据设置状态,通过业务状态判断是否需要重复执行
另外:你也可以看下这篇博客,上面是以传统电商平台支付系统为例的一套分布式事务处理实现,讲的也比较深。roncoo.com/article/deta
TCC是一个适用场景有限的模式。
很多场景下预留资源成本较高,比如可能会引入锁,对性能和可扩展性有害。
很多场景下幂等要求也不容易实现。
这种情况下考虑综合使用其他分布式一致性模式,比如补偿事务、一致性决策表等。