Seata 的 TCC 模式才是强一致性的最优解！！架构师必知

最终一致性vs强一致性

选对数据一致性方案，第一步永远是先想清楚业务场景：这活儿，到底是必须强一致，还是可以接受最终一致？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

要回答这个问题，首先得真正明白，什么叫最终一致，什么叫强一致。

其实，判断的核心依据非常明确，就这一个：在整个事务链路中，是否存在那种不符合业务预期的“中间状态”数据。

这个概念听着有点绕，咱们用个实际的例子来拆解。就拿经典的“扣库存——生成订单”流程来说。

业务流程很清晰：库存服务先执行扣减，扣减成功，再调用订单服务去生成订单。那么，我们怎么判断数据一致性呢？

业务期待的数据一致性只有两种结果：要么库存扣了、订单也成了；要么库存没动、订单也没生成。这里的关键在于，有没有可能出现第三种“别扭”的情况：库存明明扣成功了，订单却没生成；或者反过来，库存没动，订单却冒出来了。这两种，就是典型的非业务预期中间状态。

接下来，我们就拿这个标准，重点对比一下 Seata 的 AT 模式和 TCC 模式，看看它们各自会产生怎样的数据状态。

Seata的AT模式

咱们直接来看下面这张时序图，脉络会更清晰：

可以看到，在步骤8的时候，库存服务的本地数据库事务就已经提交了。注意，此时整个全局事务还没提交呢，订单服务那边甚至都还没开始。这就埋下了一个伏笔：如果这个时候，恰好有其他线程来查询这个商品的库存，它会读到什么？没错，是已经被扣减后的数量。但麻烦在于，对应的订单数据压根还没生成。这读到的，妥妥就是非业务预期的中间状态数据。

当然，如果后续订单服务一切顺利，成功生成了订单，那这个问题就被悄无声息地掩盖了，数据最终达成一致。可万一订单服务生成订单失败了，整个事务就会触发回滚，库存数量也会被还原。但之前那个读取到“已扣减库存”的线程，拿到的可就是个名副其实的“脏数据”了。在这个场景里，AT模式提供的就是一种“最终一致性”的保证。

话说回来，Seata的AT模式本质上是对传统2PC协议的一个改良。改良的关键点就在于分支事务提交的时机。在经典2PC里，所有分支事务都得等着，处理完了再一块儿提交本地事务，数据库锁持有时间很长，性能自然受影响。而AT模式做了个优化：分支事务一经处理完成，就立即提交本地事务，把锁释放掉，以此换取更高的并发能力。

这里有个细节值得注意：库存服务和订单服务的全局锁，其释放时机在正常提交和异常回滚两种情况下是不同的，而且释放速度有本质区别。这正是AT模式在多数成功场景下，性能表现出众的秘诀。

这也解释了为什么在业务成功率极高（比如99%都是成功提交）的场景里，Seata AT模式表现得格外强悍。

不过，还得提一个极端情况。在Seata AT模式中，如果第一阶段所有服务都返回成功，事务管理器发起了全局提交，但进入第二阶段后，订单服务提交时却失败了（原因可能是网络闪断、服务宕机或数据库异常）。这属于“提交阶段的异常”。

根据2PC及Seata的设计原则，一旦事务管理器决定提交（进入第二阶段），所有分支事务就必须一路走到黑，不能再回滚了。那么，第二阶段某个分支提交失败怎么办？事务协调者会负责不断重试，直到成功为止。这通常依赖于事务协调者内部的定时任务或重试队列来保证。因为第一阶段已经锁定了资源且业务校验通过，理论上第二阶段的提交操作（主要是释放锁、清理日志）是必然能够最终成功的。

Seata的TCC模式

TCC模式与Seata AT最大的不同点在于：它不依赖数据库原生的ACID特性和锁机制，而是要求开发者通过业务代码，手动实现资源的预留和最终确认。

先看Try阶段（这是核心）：

对于库存服务，不是直接扣减，而是执行“冻结”操作。比如商品总库存100件，Try阶段会冻结1件，显示可用库存99件。注意，这1件并没有被真正消耗掉，如果后续流程失败，这1件是可以被“解冻”归还的。对于订单服务，也不是直接生成一张有效订单，而是生成一个处于“中间状态”（例如“待确认”）的订单，或者仅仅预留一个订单号。这个阶段的“锁”，是业务层面的锁（比如靠一个`frozen`字段来标记），而非数据库的排他锁。这意味着其他事务仍然可以操作这行数据（只要不碰已冻结的部分），从而获得了极高的并发性。

再看Confirm阶段：

这个阶段只做一件事：确认。因为资源在Try阶段已经预留妥当，Confirm阶段理论上只应该成功，不会失败（除非遇到数据库宕机这种极端情况）。同时，Confirm操作的代码必须具备幂等性，以防网络抖动导致重复调用。

最后是Cancel阶段（图中虽未画出，但逻辑与Confirm相反）：

如果Try阶段有任何失败，事务协调者就会调用各个服务的Cancel方法。库存服务会将冻结的库存加回可用库存（解冻）；订单服务则会将那个“待确认”的订单删除或标记为“已取消”。

那么，为什么说TCC模式能提供强一致性呢？关键在于它对“中间状态”的定义。

我们以Try阶段为例，参照上图。在库存服务执行完`tryDeductStock`（步骤6）之后，基于数据库原生事务，这个操作会直接提交。此时，如果有其他线程来读取商品库存，看到的状态会是：【总库存-1 且 冻结库存数+1】。

请注意，这虽然也是业务流程中的一个中间状态，但它完全是业务预期之内的，不会产生任何歧义。无论后续流程走向如何——是订单生成失败导致库存被还原，还是订单生成成功导致冻结库存数减少——这些状态变化都完全符合事先定义好的业务语义。因此，TCC模式实现了数据的强一致性。

当然，必须强调一点：TCC所能提供的强一致性，高度依赖于业务状态定义的正确性与无歧义性。如果在Try阶段处理完后，数据状态本身就存在歧义，那么这已经不是TCC模式能解决的问题了，而是需要在业务设计层面进行修正。