TCC概念由Pat Helland于2007年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出, 在该论文中,TCC还是以Tentative-Confirmation-Cancellation命名。正式以Try-Confirm-Cancel作为名称的是Atomikos公司,并且还注册了TCC商标。国内最早可查引进TCC概念,应是阿里程立2008年在 软件开发2.0大会 上分享主题《大规模SOA系统中的分布事务处理》中。
Atomikos公司在商业版本事务管理器ExtremeTransactions中提供了TCC方案的实现,但是由于其是收费的,因此相应的很多的开源实现方案也就涌现出来,如:ByteTCC、Himly、TCC-transaction。但是笔者都不推荐使用,下文会详细说明。
TCC 是一种补偿型事务,该模型要求应用的每个服务提供 try、confirm、cancel 三个接口,它的核心思想是通过对资源的预留(提供中间态,如账户状态、冻结金额等),尽早释放对资源的加锁,如果事务可以提交,则完成对预留资源的确认,如果事务要回滚,则释放预留的资源。
TCC模型完全交由业务实现,每个子业务都需要实现Try-Confirm-Cancel三个接口,对业务侵入大,资源锁定交由业务方。
一个完整的业务活动由一个主业务服务与若干子业务服务组成:
成本:
适用范围:
TCC将事务提交划分成两个阶段,Try即为一阶段,Confirm 和 Cancel 是二阶段并行的两个分支,二选一。从阶段划分上非常像2PC,我们是否可以说TCC是一种2PC或者2PC变种呢?其实不可以,原因如下:
TCC为了解决网络不可靠引起的异常情况,要求业务方在设计上要遵循三个策略:
汇款服务、收款服务案例:A用户向B用户汇款500元。
因为TCC对业务的强侵入性,使用成本非常昂贵,虽然提供了更灵活的资源锁粒度,对标2PC拥有更高的吞吐量。但是相对于2PC的强一致性来说,TCC的实施成本和数据一致性的牺牲带来的相对高吞吐量,总体表现出来的性价比非常低,反而在市面上成熟的大型企业中几乎没有使用。
孙玄
毕业于浙江大学,奈学教育创始人兼CEO,前转转公司技术委员会主席,前58集团技术委员会主席,前百度资深研发工程师,腾讯云TVP,阿里云MVP,在线直播大课《百万架构师》品牌创始人。
林淮川
毕业于西安交通大学;奈学教育《百万架构师训练营》讲师及企业级源码内源负责人,前大树金融高级架构师、技术委员会开创者、技术总监;前天阳宏业交易事业部技术主管;多年互联网金融行业(ToB)经验。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。