在电商领域等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于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操作
- tryX 下单系统创建待支付订单
- tryY 冻结账户红包200元
- tryZ 冻结资金账户800元
Confirm操作
- confirmX 订单更新为支付成功
- confirmY 扣减账户红包200元
- confirmZ 扣减资金账户800元
Cancel操作
- cancelX 订单处理异常，资金红包退回，订单支付失败
- cancelY 冻结红包失败，账户余额退回，订单支付失败
- 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)。因此在高可用、高性能的应用场景，柔性事务是最佳的选择。
我是御狐神，欢迎大家关注我的微信公众号:wzm2zsd
参考文档
分布式事务之柔性事务
柔性事务 ：TCC两阶段补偿型
本文最先发布至微信公众号，版权所有，禁止转载！