分布式事务处理方案：Seata-Server

什么是分布式事务
首先这是普通事务：

下面是分布式事务：

在微服务系统中，每个微服务应用都可能会有自己的数据库，它们首先需要控制自己的本地事务。

一项业务操作可能会调用执行多个微服务。如何保证多个服务执行的多个数据库的操作整体成功或整体失败？这就是分布式事务要解决的问题。

CAP原则
请参考 百度百科 - CAP原则

在分布式系统中，由于网络原因出现子系统之间无法通信的情况，就会造成分区。一般分布式系统中必须容忍这种情况，那么就需要在A和C之间进行取舍。
在分布式事务中，

• 如果保证CP，就意味着要让所有子系统的数据操作要么全部成功，要么全部失败，不允许有不一致的情况发生。但是强一致性会造成性能下降。
• 如果保证AP，就意味着可以牺牲一定的一致性，允许在各个子系统中存在有的数据操作成功，有的数据操作失败的情况，只要通过后续处理，能够达到最终一致即可。

分布式事务方案

分布式事务有以下解决方案：

XA
TCC
Seata 框架 AT 事务
SAGA
可靠消息最终一致性
最大努力通知
主要对 Seata 框架 AT 事务、TCC 和 可靠消息最终一致性 三个方案进行实践。

Seata介绍
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

2019 年 1 月，阿里巴巴中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback），和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用一样，简单和高效，并逐步解决开发者们遇到的分布式事务方面的所有难题。

Fescar 开源后，蚂蚁金服加入 Fescar 社区参与共建，并在 Fescar 0.4.0 版本中贡献了 TCC 模式。

为了打造更中立、更开放、生态更加丰富的分布式事务开源社区，经过社区核心成员的投票，大家决定对 Fescar 进行品牌升级，并更名为 Seata，意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。

Seata 融合了阿里巴巴和蚂蚁金服在分布式事务技术上的积累，并沉淀了新零售、云计算和新金融等场景下丰富的实践经验，但要实现适用于所有的分布式事务场景的愿景，仍有很长的路要走。

Seata AT事务方案
Seata 的 AT 模式（Automatic Transaction）是一种无侵入的分布式事务解决方案。下面结合具体业务场景来分析其执行的原理。

业务场景
订单系统

当用户下订单时，执行以下三步流程：

订单系统保存订单
订单系统调用库存服务，减少商品库存
订单系统调用账户服务，扣减用户金额
这三步要作为一个整体事务进行管理，要么整体成功，要么整体失败。

Seata AT基本原理

Seata AT 事务分两个阶段来管理全局事务：
第一阶段： 执行各分支事务
第二阶段： 控制全局事务最终提交或回滚

第一阶段：执行各分支事务
微服务系统中，各服务之间无法相互感知事务是否执行成功，这时就需要一个专门的服务，来协调各个服务的运行状态。这个服务称为 TC（Transaction Coordinator），事务协调器。

订单系统开始执行保存订单之前，首先启动 TM（Transaction Manager，事务管理器），由 TM 向 TC 申请开启一个全局事务：

这时TC会产生一个全局事务ID，称为 XID，并将 XID 传回 TM：

这样就开启了全局事务！

全局事务开启后，开始执行创建订单的业务。首先执行保存订单，这时会先启动一个 RM（Resource Manager，资源管理器），并将 XID 传递给 RM。

RM 负责对分支事务（即微服务的本地事务）进行管理，并与 TC 通信，上报分支事务的执行状态、接收全局事务的提交或回滚指令。

RM 首先会使用 XID 向 TC 注册分支事务，将分支事务纳入对应的全局事务管辖。

现在可以执行保存订单的分支事务了。一旦分支事务执行成功，RM 会上报事务状态：

TC 收到后，会将该状态信息传递到 TM：

到此，保存订单过程结束。然后就是调用库存服务，减少商品库存，与订单的执行过程相同。

首先调用库存服务，启动 RM，并传递 XID：

库存服务的 RM 使用 XID 向 TC 进行注册，纳入全局事务管辖：

执行本地事务成功后上报状态，TC会将状态发送给TM：

相同的，完成账户分支事务：

第二阶段：控制全局事务最终提交
现在，TM（全局事务管理器）收集齐了全部分支事务的成功状态，它会进行决策，确定全局事务成功，向 TC 发送全局事务的提交请求：

然后，TC 会向所有 RM 发送提交操作指令，RM 会完成最终提交操作：

到此，全局事务全部提交完成！

第二阶段：控制全局事务最终回滚
上面是全局事务执行成功的情况，下面再来看看事务执行失败的情况。

假设订单业务执行过程中，扣减账户金额这一步分支事务执行失败，那么失败状态对TC上报，然后再发送给TM：

TM 会进行决策，确定全局事务失败，向 TC 发送全局事务的回滚请求：

然后，TC 会向所有 RM 发送回滚操作指令，RM 会完成最终回滚操作：