分布式事务之说说TCC事务
Posted ITPUB
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式事务之说说TCC事务相关的知识,希望对你有一定的参考价值。
-
数据库拆分(水平、垂直)带来的分布式事务->保证跨库操作的原子性 -
基于单个JVM
-
应用拆分带来的分布式事务->保证跨应用业务操作的原子性 -
跨JVM
-
Try:预留业务资源 -
Confirm:确认执行业务操作 -
Cancel:取消执行业务操作
-
完成所有业务检查(一致性) -
预留必须业务资源(准隔离性)
-
真正执行业务 -
不做任何业务检查 -
只使用Try阶段预留的业务资源
-
释放Try阶段预留的业务资源
-
主业务服务:主业务服务为整个业务活动的发起方,如前面提到的组合支付场景,支付系统即是主业务服务。
-
从业务服务:从业务服务负责提供TCC业务操作,是整个业务活动的操作方。从业务服务必须实现Try、Confirm和Cancel三个接口,供主业务服务调用。由于Confirm和Cancel操作可能被重复调用,故要求Confirm和Cancel两个接口必须是幂等的。前面的组合支付场景中的余额系统和红包系统即为从业务服务。
-
业务活动管理器:业务活动管理器管理控制整个业务活动,包括记录维护TCC全局事务的事务状态和每个从业务服务的子事务状态,并在业务活动提交时确认所有的TCC型操作的confirm操作,在业务活动取消时调用所有TCC型操作的cancel操作。
-
解决了跨应用业务操作的原子性问题,在诸如组合支付、账务拆分场景非常实用。
-
TCC实际上把数据库层的二阶段提交上提到了应用层来实现,对于数据库来说是一阶段提交,规避了数据库层的2PC性能低下问题。
-
TCC的Try、Confirm和Cancel操作功能需业务提供,开发成本高。
-
完成所有业务检查(一致性):检查A、B、C的帐户状态是否正常,帐户A的余额是否不少于30元,帐户B的余额是否不少于50元。
-
预留必须业务资源(准隔离性):帐户A的冻结金额增加30元,帐户B的冻结金额增加50元,这样就保证不会出现其他并发进程扣减了这两个帐户的余额而导致在后续的真正转帐操作过程中,帐户A和B的可用余额不够的情况。
-
真正执行业务:如果Try阶段帐户A、B、C状态正常,且帐户A、B余额够用,则执行帐户A给账户C转账30元、帐户B给账户C转账50元的转帐操作。
-
不做任何业务检查:这时已经不需要做业务检查,Try阶段已经完成了业务检查。
-
只使用Try阶段预留的业务资源:只需要使用Try阶段帐户A和帐户B冻结的金额即可。
-
释放Try阶段预留的业务资源:如果Try阶段部分成功,比如帐户A的余额够用,且冻结相应金额成功,帐户B的余额不够而冻结失败,则需要对帐户A做Cancel操作,将帐户A被冻结的金额解冻掉。
-
是否真正有保证跨应用业务操作的原子性需求。 -
研发上能否投入资源开发相对应的TCC接口。 -
当然还有最后一点,能否搞定一个稳定的、高可用的、扩展性强的TCC事务管理器。
大会以"架构创新之路"为主题,共设置两个主场分享时段,24个技术交流专场时段;邀请来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域,150多位技术专家及行业领袖来分享他们的经验;并将吸引4000多名系统运维、架构师、及各种企业的IT决策人士参会,为他们提供最具价值的交流平台。
以上是关于分布式事务之说说TCC事务的主要内容,如果未能解决你的问题,请参考以下文章
[分布式事务-TCC] 6. TCC的优化方案之三:二阶段异步化