在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于CAP理论以及BASE理论，有人就提出了柔性事务的概念。在业内，关于柔性事务，最主要的有以下四种类型：两阶段型、补偿型、异步确保型、最大努力通知型几种。我们前边讲过的2PC和3PC都属于两阶段型，两阶段型事务存在长期锁定资源的情况，导致可用性差。接下来我们来介绍的TCC则是补偿型分布式事务。

TCC

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个操作。

• Try：预留业务资源/数据效验；
• Confirm：确认执行业务操作；
• Cancel：取消执行业务操作。

TCC事务处理流程和 2PC 二阶段提交类似，不过2PC通常都是在跨库的DB层面，而TCC本质就是一个应用层面的2PC，如下为TCC原理图。

TCC示例

假设用户下单操作来自3个系统下单系统、资金账户系统、红包账户系统，下单成功需要同时调用资金账户服务和红包服务完成支付

假设购买商品1000元，使用账户红包200元，余额800元，确认支付。

Try操作

1. tryX 下单系统创建待支付订单
2. tryY 冻结账户红包200元
3. tryZ 冻结资金账户800元

Confirm操作

1. confirmX 订单更新为支付成功
2. confirmY 扣减账户红包200元
3. confirmZ 扣减资金账户800元

Cancel操作

1. cancelX 订单处理异常，资金红包退回，订单支付失败
2. cancelY 冻结红包失败，账户余额退回，订单支付失败
3. cancelZ 冻结余额失败，账户红包退回，订单支付失败

TCC事务的优缺点：

优点：XA两阶段提交资源层面的，而TCC实际上把资源层面二阶段提交上提到了业务层面来实现。有效了的避免了XA两阶段提交占用资源锁时间过长导致的性能地下问题。

缺点：主业务服务和从业务服务都需要进行改造，从业务方改造成本更高。以上文中的订单服务为例，2PC中只需要提供一个下单接口即可，而TCC中缺需要提供Try-Confirm-Cancel三个接口，大大增加了开发量。

TCC变种

国内厂商在TCC实战中，提出了三种TCC变种实现：

• 通用型TCC，如果我们上面介绍的TCC模型实例，从业务服务需要提供try、confirm、cancel
• 补偿性TCC，从业务服务只需要提供Do和Compensate两个接口
• 异步确保型TCC，主业务服务的直接从业务服务是可靠消息服务，而真正的从业务服务则通过消息服务解耦，作为消息服务的消费端，异步地执行。

2PC实现分布式事务分为准备阶段和提交阶段，2PC的关键是在准备阶段，在这个阶段所有参与者必须完成约束检查，达成关于分布式事务一致性的共识。第二阶段，根据之前达成的共识，完成相应的操作。提交事务的过程中需要在很多个资源节点之间进行协调，而且每个节点对锁资源的释放必须等到事务最终提交的时候。这样两阶段事务提交会耗费更长的时间。事务执行时间长意味着锁资源发生冲突的概率增加，当事务的并发量积累到一定数量的时候，很可能出现事务积压甚至出现死锁。系统的性能和吞吐量就会下降。

而柔性事务(遵循BASE理论)放弃了隔离性，减小了事务中锁的粒度，使得应用能够更好的利用数据库的并发性能，实现吞吐量的线性扩展。异步执行方式可以更好的适应分布式环境，在网络抖动、节点故障的情况下能够尽量保障服务的可用性 (Availability)。因此在高可用、高性能的应用场景，柔性事务是最佳的选择。

 

 

 原文：https://www.cnblogs.com/yuhushen/p/15520976.html