在电子商务等互联网场景下，传统事务暴露出数据库性能和处理能力的瓶颈。在分布式领域，基于CAP理论和BASE理论，有人提出了灵活事务的概念。业界主要有四种灵活交易类型：两阶段型、补偿型、异步保证型和尽力而为通知型。前面我们提到的2PC和3PC属于两阶段类型，两阶段类型事务对资源有长期锁定，导致可用性较差。我们接下来要介绍的TCC是一种补偿式分布式事务。TCCTCC交易介绍TCC方案可能是目前最流行的灵活交易方案。TCC（Try-Confirm-Cancel）的概念最早是由PatHelland在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。Try：预留业务资源/数据验证；确认：确认业务操作的执行；取消：取消业务操作的执行。TCC事务处理流程类似于2PC两阶段提交，但2PC通常是在跨库DB层面，而TCC本质上是应用层面的2PC。下面是TCC的原理图。TCC示例假设用户的下单操作来自三个系统：下单系统、资金账户系统、红包账户系统。如果下单成功，需要同时调用资金账户服务和红包服务完成支付。800元，确认付款。Try操作tryX订单系统创建待支付订单tryY冻结账户红包200元tryZ冻结资金账户800元确认操作confirmX订单更新为支付成功confirmY扣除账户红包200元confirmZ扣除资金账户800元取消操作cancelX订单处理异常，资金红包退回，订单支付失败cancelY冻结红包失败，账户余额退回，订单支付失败cancelZ冻结余额失败，账户红包退回，订单支付失败TCC交易的优缺点：优点：XAcommitat资源层面分两个阶段，而TCC其实第二阶段提交的资源层面是指业务层面来实现。有效避免了XA两阶段提交占用资源锁时间过长导致的地下性能问题。缺点：主业务服务和从业务服务都需要改造，从业务改造成本较高。以上面的订单服务为例，2PC只需要提供一个订单接口，而TCC需要提供Try-Confirm-Cancel三个接口，大大增加了开发量。TCCVariant国内厂商在TCC实战中提出了三种TCC变体实现：通用TCC，如我们上面介绍的TCC模型示例，从业务服务需要提供try、confirm、取消补偿TCC，从业务服务只需要提供Do和Compensate两个接口是异步保证的TCC。主业务服务的直接从业务服务是可靠的消息服务，而真正的从业务服务通过消息服务解耦，作为消息服务的消费者异步执行。2PC实现分布式事务分为准备阶段和提交阶段。2PC的关键是准备阶段。在这个阶段，所有参与者必须完成约束检查并就分布式事务的一致性达成共识。第二阶段，根据之前达成的共识，完成相应的操作。提交事务的过程需要很多资源节点之间的协调，每个节点释放锁资源必须等到事务最终提交。这种两阶段事务提交将花费更长的时间。事务执行时间长意味着锁资源冲突的概率增加。当事务并发累积到一定数量时，很可能会出现事务积压甚至死锁。系统的性能和吞吐量将下降。而灵活事务（遵循BASE理论）在事务中放弃了隔离性，降低了锁的粒度，使得应用能够更好地利用数据库的并发性能，实现吞吐量的线性扩展。异步执行方式更能适应分布式环境，在网络抖动和节点故障的情况下，能尽可能保证服务的可用性（Availability）。因此，在高可用、高性能的应用场景中，弹性事务是最好的选择。我是鱼虎神，欢迎大家关注我的微信公众号：wzm2zsd参考文档分布式事务：灵活事务灵活事务：TCC两阶段补偿型
