分布式事务模型--TCC

本文来说下分布式事务模式之TCC，接着上文XA Specification来说

---

概述

事务是一组不可分组的操作集合，这些操作要么都成功执行，要么都取消执行。最典型的需要事务的场景是银行账户间的转账：假如 A 账户要给 B 账户转账 100 元，那么 A 账户要扣减 100 元，B 账户要增加 100 元，这两个账户的数据变更都成功才可算作转账成功。更严格来说，可以用 ACID 四个特性表述事务：

• Atomicity：原子性，事务中的所有操作要么都成功执行，要么都取消执行，不能存在部分执行，部分不执行的状态。
• Consistency：一致性，举个例子简单的理解就是，A、B 两个账户各有 100 元，无论两个账户并发相互转账多少次，两个账户的资金总额依然是 200 元。
• Isolation：隔离性，并发事务之间的相互影响程度，隔离性也是分级别的：读未提交、读已提交、可重复读等。
• Durability：持久性，事务完成后对数据的更改不会丢失。

单体数据库不涉及网络交互，所以在多表之间实现事务是比较简单的，这种事务我们称之为本地事务。

但是单体数据库的性能达到瓶颈的时候，就需要分库(分物理实例)，就会出现跨库(数据库实例)的事务需求；随着企业应用的规模越来越大，企业会进一步进行服务化改造，以满足业务增长的需求；当前微服务架构越来越流行，跨服务的事务场景也会越来越多。

这些都是分布式事务的需求。分布式事务是指是指事务的发起者、参与者、数据资源服务器以及事务管理器分别位于分布式系统的不同节点之上。

概括起来，分布式事务有三种场景：

• 跨数据库分布式事务
• 跨服务分布式事务
• 混合式分布式事务

分布式事务中涉及的参与者分布在异步网络中，参与者通过网络通信来达到分布式一致性，网络通信不可避免出现失败、超时的情况，因此分布式事务的实现比本地事务面临更多的困难。下面介绍下常见的分布式事务解决方案之TCC。

---

TCC

TCC (Try、Commit、Cancel) 是一种补偿型事务，该模型要求应用的每个服务提供 try、confirm、cancel 三个接口，它的核心思想是通过对资源的预留（提供中间态），尽早释放对资源的加锁，如果事务可以提交，则完成对预留资源的确认，如果事务要回滚，则释放预留的资源。

TCC 也是一种两阶段提交协议，可以看作 2PC/XA 的一种变种，但是不会长时间持有资源锁。

---

TCC 模型将事务的提交划分为两个阶段

1）阶段 1

完成业务检查（一致性）、预留业务资源（准隔离性），即 TCC 中的 try。

2）阶段 2

如果 try 阶段所有业务资源都预留成功，则执行 confirm 操作，否则执行 cancel 操作：

• confirm：不做任何业务检查，仅仅使用预留的资源执行业务操作，如果失败会一直重试。
• cancel：取消执行业务操作，释放预留的资源，如果失败会一直重试。

TCC 模式中，事务的发起者和参与者都需要记录事务日志，事务的发起者需要记录全局事务和各个分支事务的状态和信息；事务的参与者需要记录分支事务的状态。

TCC 事务在执行过程中的任意环节，均可能发生宕机、重启、网络中断等异常情况，此时事务处于非原子状态和非最终一致状态，此时就需要根据主事务记录和分支事务记录的日志，去完成剩余分支事务的提交或者回滚，使整个分布式事务内所有参展达到最终一致的状态，实现事务的原子性。

---

举个例子

我们以一个简单的电商系统为例，小明在淘宝上花 100 元买了一本书，获赠 10 个积分，产品上有如下几个操作：

• 订单系统创建商品订单
• 支付系统接受小明的支付
• 库存系统扣减产品库存
• 会员系统给小明账户增加会员积分

这几个动作需要作为一个事务执行，要同时成功或者同时撤销。

如果采用 TCC 事务模式，那么各个系统需要改造为如下状态：

1）订单系统

• try：创建一个订单，状态显示为“待支付”
• confirm：更新订单的状态为“已完成”
• cancel：更新订单的状态为“已取消”

2）支付系统

• try：假设小明账户中有 1000 元，冻结小明账户中的 100 元，此时小明看到的余额依然是 1000 元。
• confirm：将账户余额变为 900 元，并清除冻结记录。
• concel：清除冻结记录。

3）库存系统

• try：假设库存中还生 10 本书，冻结其中的一本书，现实库存依然有 10 本书。
• confirm：将剩余库存更新为 9 本书，并清除冻结记录。
• cancel：清除冻结记录。

4）会员系统

• try：假设小明原因积分 3000 分，给小明账户预增加 10 积分，账户显示的积分依然是 3000 分。
• confirm：将账户积分更新为 3010，并清除预增加记录。
• cancel：清除预增加记录。

---

特点剖析

TCC 事务具备事务的四个特性：

• 原子性：事务发起方协调各个分支事务全部提交或者全部回滚。
• 一致性：TCC 事务提供最终一致性。
• 隔离型：通过 try 预分配资源的方式来实现数据的隔离。
• 持久性：交由各个分支事务来实现。

TCC 事务模型对业务方侵入较大，需要业务方把功能的实现上由一个接口拆分为三个，开发成本较高。

同时 TCC 事务为了解决异步网络中的通信失败或超时带来的异常情况，要求业务方在设计实现上要遵循三个策略：

• 允许空回滚：原因是异常发生在阶段 1 时，部分参与方没有收到 try 请求从而触发整个事务的 cancel 操作，try 失败或者没有执行 try 操作的参与方收到 cancel 请求时，要进行空回滚操作。
• 保持幂等性：原因是异常发生在阶段 2 时，比如网络超时，则会重复调用参与方的 confirm/cancel 方法，因此需要这两个方法实现上保证幂等性。
• 防止资源悬挂：原因网络异常导致两个阶段无法保证严格的顺序执行，出现参与方侧 try 请求比 cancel 请求更晚到达的情况，cancel 会执行空回滚而确保事务的正确性，但是此时 try 方法也不可以再被执行。

TCC 事务将分布式事务从资源层提到业务层来实现，可以让业务灵活选择资源的锁定粒度，并且全局事务执行过程中不会一直持有锁，所以系统的吞吐量比 2PC/XA 模式要高很多。

支持 TCC 事务的开源框架有：ByteTCC、Himly、TCC-transaction。

---

本文小结

本文详细介绍了一种分布式事务解决方案，TCC，事物补偿机制，后续会对其他分布式事务方案进行详细的介绍。