章
目
录
在分布式事务的技术领域中，TCC模式是一个重要的概念，面试中也会被经常问到CC模式原理与优势，但不少同学对它存在误解，常将其与三阶段提交混淆。实际上，TCC模式是一种独特的二阶段提交方式，与传统基于数据库事务的二阶段提交有着显著区别。本文将详细剖析TCC模式，帮助大家深入理解其原理、应用场景以及优缺点。
一、TCC模式并非三阶段提交
很多人一听到TCC（Try – Confirm – Cancel），就下意识地认为它是三阶段提交，这种理解是错误的。在分布式事务面试中，如果这样回答，很可能会给面试官留下不好的印象。实际上，TCC模式属于二阶段提交，不过它和我们通常所说的基于数据库事务的二阶段提交不同。传统的二阶段提交，比如在涉及订单中心和库存中心的业务场景中，订单中心的数据库负责处理创建订单的相关事务，库存中心的数据库负责扣库存相关事务，然后由事务管理器（如Seata）统一管理全局事务，先尝试发起事务，若各个分支都正常，再进行统一提交。关于传统二阶段提交的详细内容，之前的文章有介绍，感兴趣的同学可以去查看。
二、TCC模式的工作原理
TCC模式是传统二阶段提交的改进版本，同样分为两个阶段，即先尝试发起事务，如果都正常就进行Confirm操作（类似提交），如果失败则直接进行Cancel操作（类似回滚） 。但它最大的特点是抛弃了数据库的原生事务，将所有事务处理，包括尝试处理、提交和回滚，都提升到业务层进行处理。这意味着开发人员需要自己编写详细的业务逻辑代码。
以常见的下单扣库存场景为例，在Try阶段，也就是准备阶段，需要真实地创建订单，但订单状态是预创建状态，尚未正式生效；库存的扣减也不是真正意义上的扣减，而是处于预扣除状态。比如，可以引入库存预扣表，先将库存冻结起来。当各个分支都准备完成后，通知事务管理器可以提交了，此时才进入Confirm阶段。在这个阶段，会删除中间的冻结记录，在库存主表中真正扣减库存，同时将订单状态转为正常状态，整个事务才算完成。
三、TCC模式应对失败的策略
当事务处理过程中出现失败情况时，TCC模式的处理方式会因阶段不同而有所差异。如果是在Try阶段失败，比如库存不足无法完成预扣减，那么直接进行Cancel操作，回滚所有已执行的操作，这比较容易理解。但如果在Confirm阶段失败，由于部分操作可能已经生效，无法像Try阶段那样直接回滚，此时只能通过不断重试，直到成功为止。当然，重试操作一般由事务管理器来管理。只要代码质量过关，经过充分测试，并且Try阶段能有效检查出大部分问题，Confirm阶段通常是可以成功的。
四、TCC模式的优缺点
TCC模式在实际应用中有其独特的优势和不足。从代码层面来看，它的开发和维护成本较高。因为所有事务逻辑都需要在业务层手写，代码侵入性很强，业务逻辑会变得相当复杂，尤其是经过多个版本的迭代后，后续维护人员理解和修改代码的难度较大，相比XA、AT模式，在代码友好度上表现欠佳。
不过，从接口效率的角度分析，TCC模式有着明显的优势。由于它不依赖数据库事务，没有全局事务锁定，在高并发场景下，接口访问不会被阻塞，相对而言接口的响应效率得到了提高。
分布式事务的TCC模式适用于对接口响应效率要求较高、业务逻辑相对可控且对代码维护成本有一定承受能力的场景。在实际项目开发中，我们需要根据具体的业务需求和系统架构，综合权衡各种分布式事务模式的利弊，选择最适合的方案。如果大家对TCC模式还有其他疑问或者想要分享自己的经验，欢迎在评论区留言讨论。
