微服务架构下的分布式事务选型指南：2PC、3PC、AT、Saga与Seata详解

根据多年的开发经验，在搭建项目框架时，一定要贴合业务需求，切忌一开始就追求“放之四海而皆准”的超级微服务或高扩展性分布式架构。否则很容易陷入“人手少了自己累，人手多了公司累”的尴尬境地。

我的原则是：能用单体服务解决的，就不用微服务；能用Nginx水平扩展解决的，也不用微服务。即使采用了微服务，能不拆分的业务就不要拆分。这就像能一个人完成的工作，绝不分给N个人。采用微服务不是为了“微”而拆分，而是为了清晰的业务边界。例如，订单和库存如果强耦合，就可以放在一个服务里不拆分；而订单与物流的边界相对清晰，就可以将物流服务拆分出来。

那么，为什么我们还需要学习分布式事务呢？坦率地说，大约80%的动力可能来自面试准备，剩下的20%则是为了知识储备，为未来可能遇到的场景（比如新入职的公司已经在使用）做好准备，毕竟有时候你没得选。

首先，我们来回顾一下事务的根基：ACID四大特性。

主流的分布式事务方案及实现方式如下图所示，主要分为基于XA协议和基于补偿/最终一致性两大技术路径。

1. 2PC事务模式

2PC是基于数据库层面实现的强一致性事务方案。

2PC（准备 -> 提交）需要两个步骤执行。它引入了一个“事务协调者”角色来管理各个参与者（微服务）的事务。流程分为两个阶段：准备阶段和提交/回滚阶段，即准备->提交成功，或准备->回滚。

• 第一阶段：协调者向所有参与者发送“准备”命令。每个参与者收到命令后，会执行本地事务操作（开启事务流程），但不提交事务，然后向协调者反馈“成功”或“失败”。
• 第二阶段：协调者根据所有参与者的反馈决定全局事务的最终状态。如果全部反馈“成功”，则向所有参与者发送“提交”命令；如果任一参与者反馈“失败”，则向所有参与者发送“回滚”命令。参与者根据收到的命令执行本地事务的提交或回滚。

优点：它直接利用了数据库本身的事务能力，对业务代码无侵入，事务的提交与回滚完全由数据库完成。

缺点也非常明显：

1. 同步阻塞：在准备阶段到最终提交/回滚前，相关资源会被锁定，阻塞其他操作，影响系统并发性能。
2. 单点故障与资源浪费：协调者单点故障可能导致参与者长期锁定资源。此外，若有一个参与者失败，其他已执行准备的参与者所做的操作最终也会被回滚，造成一定的资源浪费。

正是为了缓解2PC的阻塞问题，在其基础上增加了一个预检阶段，从而衍生出了3PC。

2. 3PC事务模式

3PC将事务过程分为三个阶段：

1. CanCommit阶段：协调者询问参与者是否具备执行事务的条件，参与者进行自身状态检查并反馈。这是一个“预检”阶段，不锁定资源。
2. PreCommit阶段：如果所有参与者都反馈“可以”，协调者发送“预提交”命令，参与者执行事务操作但不提交（类似于2PC的准备阶段）。如果有参与者反馈“不可用”，则协调者发送“中止”命令。
3. DoCommit阶段：协调者根据第二阶段的结果，发送最终的“提交”或“回滚”命令。

2PC和3PC都属于强一致性事务模型，通常在对数据一致性要求极高的场景中使用，例如金融交易，以保证资金绝对安全。

3. AT事务模式

AT模式是一种基于最终一致性的流行方案，也是Seata框架最常用的事务解决方案。它对业务代码侵入小，并发性能较好。

其核心思想是基于UNDO LOG实现数据回滚。在每个参与者执行本地事务时，会同时生成一份数据更新前的快照（UNDO LOG）并随事务一起提交。整个过程分为两个阶段：

• 第一阶段：各参与者执行本地业务SQL并直接提交，同时将数据的前后镜像生成UNDO LOG，然后向协调者报告本地事务状态（成功/失败）。
• 第二阶段：协调者根据第一阶段的报告决定全局事务是提交还是回滚。
  • 全局提交：协调者异步通知各参与者删除对应的UNDO LOG即可。
  • 全局回滚：协调者通知各参与者，参与者根据UNDO LOG中的“前镜像”进行数据恢复，然后再删除UNDO LOG。

这里的UNDO LOG由Seata框架自动生成和管理，开发者无需手动介入，因此对业务代码几乎无侵入。

4. TCC事务模式

TCC指Try、Confirm、Cancel，是需要业务层实现的三个方法，因此代码侵入度很高。它分为两个阶段：

• 第一阶段 - Try：资源检查和预留。尝试执行业务，完成所有业务检查，并预留必需的资源。
• 第二阶段：根据第一阶段的结果执行Confirm（提交）或Cancel（回滚）。
  • Confirm：确认执行业务，使用Try阶段预留的资源，真正完成业务操作。
  • Cancel：取消执行业务，释放Try阶段预留的资源。

可以将其比作考试：第一阶段（Try）是把题目在草稿纸上做完；第二阶段（Confirm）是把正确答案正式誊写到答题卡上，若发现草稿纸上的过程有误，则进入Cancel阶段擦掉重写。

例如，创建订单并扣减库存的场景：

• Try：创建订单（状态为“待支付”），库存不实际扣减，而是冻结相应数量。
• Confirm：订单状态不变（已创建），库存实际扣减，冻结数量清零。
• Cancel：删除已创建的订单，库存的冻结数量清零。

TCC模式虽然需要开发者手动实现补偿逻辑，开发复杂度高，但对比AT模式，它没有全局锁，性能更好，且业务控制更灵活。

5. Saga事务模式

Saga模式是一种分布式异步事务，属于最终一致性柔性事务，又称“长事务”。

它由一系列有序的本地事务（子事务Ti）组成，每个Ti都有对应的补偿动作Ci（用于撤销Ti造成的结果）。与TCC不同，Saga没有“预留”动作，每个Ti都是直接提交的。

Saga只有两个阶段：

1. 第一阶段：按顺序执行所有子事务T1, T2, ..., Tn，每个子事务执行完立即提交。
2. 第二阶段（仅在失败时触发）：如果某个子事务Tk执行失败，则按相反顺序Ck-1, ..., C1执行补偿操作，回滚前面已成功的事务。

由于每个子事务都已提交，在补偿时可能遇到“无法回滚”的情况，尤其是调用第三方接口（如发送邮件）。邮件一旦发出并被阅读，就无法撤回，补偿操作只能是再发一封说明邮件进行修正。

6. 本地消息表模式

本地消息表也是一种实现最终一致性的常见方法，其核心思想是将分布式事务拆解为本地事务和异步消息。

• 第一阶段：事务参与者A在执行本地业务操作并提交事务的同时，将需要发送给参与者B的消息作为一条记录，插入到本地数据库的专用消息表中（这是一个本地事务）。然后，通过后台任务异步地将该消息投递给B。
• 第二阶段：参与者B消费消息，执行自身的本地事务。执行成功后，可以回调通知A更新消息状态，或由A定时轮询B的状态。如果B处理失败或消息投递失败，则通过定时任务重试；达到最大重试次数后，将消息标记为“待人工处理”或转入死信队列。

关于 Seata 的补充

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。它通过多种事务模式帮助开发者在分布式系统中保证数据一致性。

Seata 的核心组件包括：

• Transaction Coordinator (TC)：事务协调器，负责维护全局事务的运行状态，驱动全局事务的提交或回滚。独立部署。
• Transaction Manager (TM)：事务管理器，定义了全局事务的边界，负责开启、提交或回滚全局事务。集成在业务应用中。
• Resource Manager (RM)：资源管理器，负责管理分支事务（本地事务）处理的资源，向TC注册分支事务、报告状态，并接收TC的指令来驱动分支事务的提交或回滚。集成在业务应用中。

Seata 支持上文提到的多种事务模式：

• AT 模式：其实现依赖于支持本地ACID事务的关系型数据库（如MySQL）。它是Seata的默认和主流模式，对应用侵入低。
• TCC 模式：提供更高的灵活性，但需要业务实现Try、Confirm、Cancel接口，开发成本较高。
• SAGA 模式：适用于业务流程长、需要跨多服务的场景，每个服务提交本地事务，失败时逆向补偿。
• XA 模式：基于数据库对XA协议的支持，实现强一致性，但通常性能开销最大。

选择哪种模式，需要根据业务对一致性、性能、开发复杂度的要求进行权衡。例如，对于常见的电商交易场景，AT模式往往是一个不错的起点；而对于涉及复杂业务校验和资金处理的场景，可能需要考虑TCC模式提供的更细粒度控制。理解这些模式的原理，是我们在云栈社区进行技术选型和架构设计时做出正确决策的基础。