TCC的应用场景

TCC
TCC（Try、Confirm、Cancel）是两阶段提交的一个变种。TCC提供了一个框架，需要应用程序按照该框架编程，将业务逻辑的每个分支都分为Try、Confirm、Cancel三个操作集。TCC让应用程序自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。

以一个典型的淘宝订单为例，按照TCC框架，应用需要在Try阶段将商品的库存减去，将买家支付宝账户中的相应金额扣掉，在临时表中记录下商品的数量，订单的金额等信息；另外再编写Confirm的逻辑，即在临时表中删除相关记录，生成订单，告知CRM、物流等系统，等等；以及Cancel逻辑，即恢复库存和买家账户金额，删除临时表相关记录。

我们能找到的最早出处是atomikos的ExtremeTransactions产品中提出了TCC的概念。在撰写本文时，atomikos网站不能访问，只能在百度百科里面找到一篇 相关的文章。目前，TCC概念最大的应用，一般认为是支付宝XTS系统。

为了更好地介绍TCC，这里先引入这么一个概念：最终一致性

最终一致性目前没有公认的定义。一般来说，它是指事务进行中，某些分支的中间状态可以被事务外观察到，即"读未提交"，从而导致多个分支的状态可能不一致，但所有分支 最终 会达到要么全部提交，要么全部回滚的一致状态。

很明显，最终一致性部分牺牲了ACID中的C和I，但它带来了可观的收益：资源不再需要长时间上锁，极大地提高了吞吐量。

最终一致性在互联网应用场景中被广泛用做吞吐量和ACID的妥协点。

让我们回到前面TCC的例子。在这个流程中，商品库存和买家余额都没有被锁住，因此可以得到很高的吞吐量。但在交易进行中，商品库存和买家余额的变化就已经被外界感知到，而物流系统却可能还没有相应的记录，此时数据是不一致的，但最终（无论是Confirm阶段结束后，还是Cancel阶段结束后）它们会一致。