脚本宝典收集整理的这篇文章主要介绍了分布式事务(四)之TCC,脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。
在电商领域等互联网场景下,传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论,有人就提出了柔性事务的概念。在业内,关于柔性事务,最主要的有以下四种类型:两阶段型、补偿型、异步确保型、最大努力通知型几种。我们前边讲过的2PC和3PC都属于两阶段型,两阶段型事务存在长期锁定资源的情况,导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。
TCC方案是可能是目前最火的一种柔性事务方案了。关于TCC(Try-Confirm-Cancel)的概念,最早是由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。在该论文中,TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司,其注册了TCC商标。国内最早关于TCC的报道,应该是InfoQ上对阿里程立博士的一篇采访。经过程博士的这一次传道之后,TCC在国内逐渐被大家广为了解并接受。
TCC将事务提交分为Try-Confirm-Cancel 3个操作。
TCC事务处理流程和 2PC 二阶段提交类似,不过2PC通常都是在跨库的DB层面,而TCC本质就是一个应用层面的2PC,如下为TCC原理图。
假设用户下单操作来自3个系统下单系统、资金账户系统、红包账户系统,下单成功需要同时调用资金账户服务和红包服务完成支付
假设购买商品1000元,使用账户红包200元,余额800元,确认支付。
优点:XA两阶段提交资源层面的,而TCC实际上把资源层面二阶段提交上提到了业务层面来实现。有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能地下问题。
缺点:主业务服务和从业务服务都需要进行改造,从业务方改造成本更高。以上文中的订单服务为例,2PC中只需要提供一个下单接口即可,而TCC中缺需要提供Try-Confirm-Cancel三个接口,大大增加了开发量。
国内厂商在TCC实战中,提出了三种TCC变种实现:
2PC实现分布式事务分为准备阶段和提交阶段,2PC的关键是在准备阶段,在这个阶段所有参与者必须完成约束检查,达成关于分布式事务一致性的共识。第二阶段,根据之前达成的共识,完成相应的操作。提交事务的过程中需要在很多个资源节点之间进行协调,而且每个节点对锁资源的释放必须等到事务最终提交的时候。这样两阶段事务提交会耗费更长的时间。事务执行时间长意味着锁资源发生冲突的概率增加,当事务的并发量积累到一定数量的时候,很可能出现事务积压甚至出现死锁。系统的性能和吞吐量就会下降。 而柔性事务(遵循BASE理论)放弃了隔离性,减小了事务中锁的粒度,使得应用能够更好的利用数据库的并发性能,实现吞吐量的线性扩展。异步执行方式可以更好的适应分布式环境,在网络抖动、节点故障的情况下能够尽量保障服务的可用性 (Availability)。因此在高可用、高性能的应用场景,柔性事务是最佳的选择。
我是御狐神,欢迎大家关注我的微信公众号:wzm2zsd
分布式事务之柔性事务 柔性事务 :TCC两阶段补偿型
本文最先发布至微信公众号,版权所有,禁止转载!
以上是脚本宝典为你收集整理的分布式事务(四)之TCC全部内容,希望文章能够帮你解决分布式事务(四)之TCC所遇到的问题。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。