读完这一篇，我不信你还不懂分布式事务TCC

码农在囧途

你现在的苦闷、内心斗争、理想与现实的差距，我都知道，但是我没有办法替你承担，这些都需要你自己去慢慢体会、琢磨、看开、悟透，总结，然后继续向前！

前言

前面我们说了两期分布式事务模型，分别是2PC和3PC，2PC模型它的效率比较低，并且会出现事务阻塞等问题，所以引入了3PC模型， 3PC模型在2PC模型的基础上进行了改进，避免了事务阻塞问题，不过对于2PC和3PC模型，他们依然是阻塞的，也就是说当前事务在执行的过程中，其他事务都会被阻塞，所以实际上他们的效率都不高，如果对于并发量不发的系统，那么可以选择它们，但是在高并发的场景下，用2PC模型和3PC模型，显然就不行了，所以今天我们引入了TCC模型。

TCC解释

前面的2PC，3PC属于强一致性分布式事务，TCC属于最终一致性分布式事务，T是Try，第一个C是Confirm，第二个 C是Concel，这三个过程都需要工程师自己去编码，所以TCC对业务的入侵很大，它的作用就是帮我们协调，但实际逻辑需要我们自己去编码，但是TCC的效率比较高，不存在事务阻塞，高并发场景下比较适合。

深入分析

我们用一个下单过程来说明TCC的工作机制，正常的下单会包含创建订单，扣减库存，扣减账户余额，增加积分等功能，所以会调用这些子系统，有的系统使用http进行远程调用，有的使用rpc进行调用，我们这个例子中有五个微服务，分别为业务微服务(BusinessMicroservice), 库存微服务(StockMicroservice)，订单微服务(OrderMicroservice)，积分微服务(IntegralMicroservice), 账户微服务(AccountMicroservice)，在业务微服务中通过rpc统一调用其他微服务。

使用TCC就需要设计三部分的业务代码，分别是Try阶段，Confirm阶段，Concel阶段。

Try

从字面意思我们看出Try是尝试的意思，这个阶段其实就是对资源进行预留，需要工程师自己去设计，在Try阶段代码设计的好坏，在很大程度上影响整个分布式事务的结果，所以对工程师的设计能力和思考能力有一定的考验。

预扣减库存

这一步并没有真正地扣减库存，所以叫做预扣减库存，首先先检查库存是否被扣减，比如我下单量为2，此时库存为1，那么显然不能扣减，如果库存为 10，那么证明可以扣减，但是此时并不会真正地扣减库存，我们需要对其进行一些设计，这需要根据自己的业务场景去设计，比如可以新建一个冻结库存的表，因为下单量为2，库存为10，所以此时执行10-2，库存为8，我们就将库存更新为8，然后在库存冻结表中插入一条扣减记录，记录是某个用户的下单数量，，那么扣减库存这一步就完成了。

预创建订单

预创建订单也不是真正地创建订单，我们可以将订单的状态改为创建中，这个状态值只是用来表示订单的状态，这个状态并非真实订单的状态，而是为了使用分布式事务而使用的状态，并不是商品生命周期中的属性。

预增加积分

这里也不是真正地增加积分，我们可以在积分记录中添加一个冻结积分字段，例如，积分余额为100，需要增加的积分20，那么此时积分余额值就变为120(100+20)，冻结积分为20。

预扣减余额

扣减余额我们在账户表中添加一个冻结字段，例如，如果账户余额为1000，本次需要扣减200，那么此时余额就变为800(1000-200)，冻结金额为200。

到这里，Try阶段我们就说完了，我们发现，在Try阶段我们做的事就是在预留资源。

Confirm

如果Try阶段所有的业务都成功地执行完毕，没有出现错误，那么在Confirm阶段就会执行所有分支事务，这个阶段唯一做的就是提交事务(完成我们自己定义的逻辑), 不会再去校验数据，比如库存是否充足等，因为第一阶段已经检验过并且通过了。

扣减库存

因为库存表中在Try阶段已经减过库存，只是扣减记录保存在了库存冻结表，所以这一步就需要删除冻结表的记录，通过用户Id去删除。

设置订单状态为已创建

Try阶段将订单状态设置为创建中，到了这里就需要将订单状态设置为已创建，代表订单事务已经完成。

增加积分

这里的增加积分在Try阶段其实已经做了，只是预留了一个冻结积分，所以这里就需要更新冻结积分，将其更新为0，代表增加积分这个事务已经完成。

扣减余额

这里的扣减余额在Try阶段已经做了，只是预留了一个冻结金额，所以这里就需要更新冻结金额，将其更新为0，代表扣减余额事务已经完成。

到这里TCC的Confirm就完成了，Confirm阶段唯一做的事情就是执行任务，不做任何的数据校验。

Cancel

上面的Confirm阶段是Try阶段所有的操作都正常，没有出错，如果有一种的一个操作出现异常或资源出错，那么就会进入Cancel 阶段，Cancel阶段会对Try阶段的所有操作进行回滚，也就是将数据恢复到刚开始的时候。

恢复库存

恢复库存就是查询库存冻结表中的冻结库存，然后加上库存表中库存(库存表库存 = 库存表库存 + 冻结库存)， 8 + 2 = 10 ，然后删除冻结库存记录，代表事务回滚成功。

设置订单状态为取消

Try阶段订单状态为创建中，那么因为在Try阶段某个分支事务出错，所以需要将订单状态置为已取消(这个状态并不是订单生命周期中的状态)，而是为事务设计的状态，代表事务回滚成功。

恢复积分

用冻结积分加上积分余额(积分余额 = 积分余额 + 冻结积分)，然后更新到积分余额上，随后将冻结积分更新为0，代表事务回滚成功。

恢复余额

用冻结余额加上余额(余额 = 余额+ 冻结余额)，更新到余额上面，将冻结余额更新为0，代表事务回滚成功。

Cancel阶段就完成了，Cancel阶段主要是对各个事务进行恢复，他是基于Try阶段的数据进行恢复。

总结

完成了TCC的分析，我们可以看出TCC事务之间并没有阻塞，但是事务的成败很大一部分是掌握在开发人员的手上，因为它不像2PC模式的框架完全是由框架来帮我们完成事务的提交和回滚，在TCC模式中，事务的提交回滚都是要由我们去编写业务代码来实现，TCC帮我们做的是对任务的调度，感知分支事务是否正常，再根据结果进行提交或者回滚，所以，我们编写代码的好坏直接影响到TCC事务是否成功。

从上面的例子中，我们其实不难看出，TCC事务并不能完全保证事务的一致性，在Try阶段，如果所有分支都正常，那么其实在Confirm阶段基本上都能成功，如果Try阶段失败，那么在Cancel阶段其实也基本能成功，如果在Confirm阶段和Cancel没成功，那么TCC框架就会重试，或者需要人工进行处理，所以数据的一致性并不能完全得到保障。