在电商畛域等互联网场景下，传统的事务在数据库性能和解决能力上都暴露出了瓶颈。在分布式畛域基于 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 两阶段弥补型
本文最先公布至微信公众号，版权所有，禁止转载！