[分布式事务-TCC] 6. TCC的优化方案之三：二阶段异步化

二阶段异步化

采用TCC模型实现分布式事务之后，分布式事务所需的资源也是按照业务的维护进行切分，每笔分布式事务之间的资源都是独立预留和消费。

单说这些可能有点难理解举个栗子就很容易理解了，账户A同时参与了两笔分布式事务，一笔是转账50元到账户B；另一笔是转账100元到账户C。

那么每笔分布式事务都会各自预留所需的资源，它们感知不到彼此的存在，也不会互相干扰。这里顺便复习一下实现TCC模型的一个关键点：业务模型的重构。

对于转账这个场景而言，是通过将原账户的余额字段一拆为三来实现的：

1. 可用余额
2. 未达金额
3. 未出金额(预留资源)

优化方案都是依托于系统的运行时和业务的实际需要。在转账这个业务场景下，数据不一致的时间是很短的，当我们转账的时候，我们也是希望这笔交易能够在很短的时间内完成，否则我们肯定会认为银行不靠谱，进而产生很大的不安全感。所以，业务上就决定了转账对RT的要求很高，一阶段执行完了二阶段马上就要执行。

但是天底下的业务场景何其多，不是所有业务都需要这么极端的RT保证。

一笔交易的链路其实是很长的，收单只是万里长征第一步，后面还涉及到计收费，结算等各个环节。收了买家的钱，需要将这笔钱打到卖家的账户上。但是在现实中，卖家一般都不会实时地就能够收到这笔钱，而是通过记账的方式记录下来这笔收入，保证可以准实时地看到这笔交易出现在账单中，然后根据和收单服务方约定的结算周期(比如周，半月，月等)完成结算。

所以对结算这个业务场景，TCC一阶段执行成功后，二阶段并不一定需要马上就执行。

再举个例子，在