分布式事务之Try-Confirm-Cancel，简称tcc
比如我把500元从某个银行卡账户转入到微信钱包。那么对微信这边的转入接口进行的操作便是一个补偿操作。
看到这里，你可能在想，原来是调用一个远程接口啊。没错，直接去调用现有的远程接口就是一种补偿操作。
除了这种补偿外，还有另外一种补偿方式。那就是TCC，也就是Try-Confirm-Cancel。
补偿方式：
直接方式
TCC
那接下来就重点来说TCC。
TCC的方式和直接方式其实都是调用服务方提供的接口。但他们有所不同的是，直接方式更加的简单，不用服务提供方再额外提供接口就可以实现业务。
而TCC则需要服务方提供更多更具体的接口，分别有Try接口、Confirm接口和Cancel接口。
TCC相比直接方式的好处就是在有的场景下，TCC让你的分布式事务更加的符合业务体验。
比如买飞机票的例子。我要买机票从布鲁塞尔到多伦多。这是一个事务，可以分为两个部分，从布鲁塞尔到华盛顿的航班和从华盛顿到多伦多的航班。假设这两张机票分别有自己的预订系统。那么此时如果用直接方式来实现补偿的后果就是，我可能买到了一张布鲁塞尔到华盛顿的机票，但却没有买到华盛顿到多伦多的机票，此时我就得急匆匆的又去看看华盛顿到多伦多其他时间段的航班，毕竟买到手的机票退起来还是比较麻烦的。这显然是不友好的。
而此时如果使用TCC的方式，我先分别对布鲁塞尔到华盛顿和华盛顿到多伦多的机票进行Try，也就是仅仅占用一个名额（仅仅是预留）。然后第二阶段的时候，我才真正决定自己要不要最终下单，如果两个都成功Try，那么就最终下单，然后把状态改为CONFIRMED，如果第二张机票没有成功Try，那么依然还有机会去取消第一张机票，把第一张机票改为CANCELED。
上面我们已经对比了直接方式和TCC两种方式。可以发现TCC在特定的场景，比如预订有限资源的购买场景下就非常适合，通过Try来预留资源，然后通过confirm和cancel两个补偿动作来最终决定是否购买。
当然有的场景下，使用直接方式则显得更加的简单，而不需要服务提供方提供额外的接口。比如买股票。股票买就买了，赔就赔了，也不需要TCC如此稳妥的方式，哈哈。
TCC开源实现
TCC开源框架，比较著名的有Atomikos、国内的TCC-transaction。更多框架欢迎补充。
总结
通过上面的梳理，我们首先明确了事务的概念：完成一件事情。然后明白事务中是由多个片段来组成。然后明确了两种事务一致性标准ACID和BASE。然后我们明确了补偿这一概念。补偿有两种方式，直接方式和TCC的方式。且在诸多BASE中，TCC是在特定的预订购买场景下较为适合的处理方式之一。