微服务分布式事务解决方案-开源软件seata
分布式事务是分布式系统中非常重要的一部分。假设一个用户购买商品的业务逻辑，系统有3个微服务组成，分别是订单服务、账户服务、库存服务，用户在提交订单后会从用户账户余额中扣款，同时扣减库存数量。在这样的场景下扣款和减库存需要事务一致性保证。就可能会使用到分布式事务解决方案。
分布式事务的实现可以采用不同的技术和协议，例如两阶段提交（2PC）、三阶段提交（3PC）、基于消息队列的事务等。这些方法和协议都致力于确保在分布式环境下的事务状态的一致性和可靠性。
一、分布式事务开源组件Seata
在分布式事务开源组件和解决方案中，最广泛应用的是蚂蚁金服开源的 Seata。Seata 是一个开源的分布式事务解决方案，在微服务架构下提供高性能、易用的分布式事务服务。在Seata开源之前，其内部版本一直扮演着阿里巴巴集团应用架构层数据一致性的中间件角色，帮助经济顺利度过过去一年的双11，为上层业务提供了强大的技术支撑。经过多年的发展，其商用产品已在阿里云和金融云上销售。2019.1 为了打造更完善的技术生态和包容性的技术成果，Seata正式宣布对外开源。
1.1、Seata分布式事务架构
Seata的设计思想是将一个分布式事务拆分为包含多个分支事务（Branch Transaction）的全局事务（Global Transaction）。每个分支事务表示一个本地事务，具备ACID特性。全局事务的责任是协调管理其下属的分支事务，以实现统一的一致性。要么一起成功提交，要么一起回滚。
Seata事务管理中有三个重要的角色：
- TC(Transaction Coordinator)-事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
- TM(Transaction Manager)-事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
- RM(Resource Manager)-资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
TM会首先注册全局事务，之后业务调用各个微服务，由各自的RM向TC发起分支事务的注册，之后执行各个分支事务的sql，执行完毕之后RM会向TC报告分支事务的状态，所有分支事务执行完毕之后，TM向TC发起提交或回滚全局事务，此时TC会检查分支事务的状态来决定是提交还是回滚发送给RM。
以上只是Seata分布式事务的基本模型。
1.2、分布式事务模型
解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务.
名词解析：
全局事务：整个分布式事务
分支事务：分布式事务中包含的每个子系统的事务
最终一致性：各分支事务分别执行并提交，如果有不一致的情况，想办法补偿恢复，达到数据的最终一致性
强一致性：各事务执行完业务不要提交，等待彼此结束，之后统一提交或回滚
二、分布式事务XA、AT、TCC、SAGA模式
Seata提供了XA、AT、TCC、SAGA四种不同的分布式事务解决方案：
（1）XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入。
（2）TCC模式：最终一致的分阶段事务模式，有业务侵入。
（3）AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式。
（4）SAGA模式：长事务模式，有业务侵入。
2.1、XA模式
XA规范是X/Open组织定义的分布式事务处理(DTP，Distributed Transaction Processing)标准，XA规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对XA规范提供了支持。
标准的XA模式为两阶段提交：
第一阶段由事务协调者向RM(XA模式下一般由数据库实现)发起事务准备请求，RM执行完毕之后，并不直接提交事务，而是将执行的结果告知事务协调者。
第二阶段由事务协调者判断RM的返回结果，如果分支事务都成功了，向RM发起提交请求，RM执行事务提交并返回已提交请求。
但是，如果在事务执行过程中有一个失败了，事务协调者则会回滚所有已执行事务。
Seata在实现XA模式时进行了一定的调整，但大体上相似：
RM一阶段工作：
- 注册分支事务到TC
- 执行分支业务SQL但不提交
- 报告执行状态到TC
TC二阶段工作：
- TC检测各分支事务执行状态
- 如果都成功，通知所有RM提交事务
- 如果有失败，通知所有RM回滚事务
RM二阶段工作：
- 接受TC指令，提交或回滚事务
2.1.1、XA模式总结
优点：
- 事务强一致性，满足ACID原则
- 常用数据库都支持，实现简单，没有代码侵入
缺点：
- 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，所以性能较差
- 依赖关系型数据库实现事务
2.2、AT模式
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
AT模式在执行完sql之后会直接提交事务，而不是进行等待，在执行的同时RM拦截本次执行，记录更新前后的快照到数据库的undo_log中。与XA的不同之处在于阶段一RM的工作：
- 注册分支事务
- 记录undo-log(数据快照)
- 执行业务sql并提交
- 报告事务状态
阶段二提交时RM的工作：
- 删除undo-log即可
阶段二回滚时RM的工作：
- 根据undo-log回复数据到更新前
具体案例：例如，一个分支业务的SQL是这样的：update tb_account set money = money - 10 where id = 1
如果这条sql执行成功，那么money字段自然是90，如果执行失败，则根据数据快照恢复数据。
AT工作模型
2.2.1、AT模式总结
Seata AT模式是一种非侵入式分布式事务解决方案。Seata 在内部实现了一个用于数据库操作的代理层。在使用 Seata AT 模式时，我们实际上使用的是 Seata 提供的内置数据源代理 DataSourceProxy。Seata 在此代理层中添加了很多逻辑，例如插入回滚undo_log记录和检查全局锁。
为什么要检查全局锁？这是因为 Seata AT 模式的事务隔离是基于支持事务的本地隔离级别。在数据库本地隔离级别为读取提交或以上的前提下，Seata 设计了一个由事务协调器维护的全局写独占锁，以保证事务之间的写入隔离。同时，默认情况下，全局事务在读取未提交隔离级别定义。
与XA模式最大的区别是：
- XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
- XA模式强一致；AT模式最终一致
优点：
- 一阶段完成直接提交事务，释放数据库资源，性能比较好
- 利用全局锁实现读写隔离
- 没有代码侵入，框架自动完成回滚和提交
缺点：
- 两阶段之间属于软状态，属于最终一致
- 框架的快照功能会影响性能，但比XA模式要好很多
2.3、TCC模式
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：
- Try：资源的检测和预留；
- Confirm：完成资源操作业务；要求Try成功Confirm一定要能成功。
- Cancel：预留资源释放，可以理解为Try的反向操作。
举例，一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。
- 阶段一(Try): 检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
- 阶段二：假如要提交（Confirm），则冻结金额扣减30
- 阶段三：如果要回滚（Cancel），则冻结金额扣减30，可用余额增加30
TCC工作模型图：
TCC是一种侵入式分布式事务解决方案。这三项操作都需要由业务系统本身实现，这对业务系统有重大影响。设计相对复杂，但优点是TCC不依赖数据库。它可以跨数据库和应用程序管理资源，并可以通过侵入式编码实现不同数据访问的原子操作，更好地解决各种复杂业务场景中的分布式事务问题。
2.3.1、TCC模式总结
TCC模式的每个阶段是做什么的？
- Try：资源检查和预留
- Confirm：业务执行和提交
- Cancel：预留资源的释放
TCC的优点是什么？
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 相比AT模型，无需生成快照，无需使用全局锁，性能最强
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
TCC的缺点是什么？
- 有代码侵入，需要人为编写try、Confirm和Cancel接口
- 软状态，事务是最终一致
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理
2.4、SAGA模式
Saga模式是SEATA提供的长事务解决方案。也分为两个阶段：
- 一阶段：直接提交本地事务(TCC是预留)
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
Saga模式优点：
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
缺点：
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
SAGA模式下，事务一旦有一个出现问题，则反向按照事务调用顺序进行补偿，从而保证一致性。
三、分布式事务模型对比总结
|
XA |
AT |
TCC |
SAGA |
|
|
一致性 |
强一致 |
弱一致 |
弱一致 |
最终一致 |
|
隔离性 |
完全隔离 |
基于全局锁隔离 |
基于资源预留隔离 |
无隔离 |
|
代码侵入 |
无 |
无 |
有，需要编写3个接口代码 |
有，需要编写状态机和补偿业务 |
|
性能 |
差 |
好 |
非常好 |
非常好 |
|
场景 |
对一致性、隔离性有高要求的业务 |
基于关系型数据库的大多数分布式事务场景都可以 |
对性能要求较高的事务；有非关系型数据库要参与的事务 |
业务流程长、业务流程多；参与者包含其它公司或遗留系统服务，无法提供TCC模式要求的三个接口 |
总结：
Seata分布式事务框架提供的这四种模式适用于不同应用场景，XA和AT是基于数据库层面的分布式事务，TCC和SAGA是基于业务层面的分布式事务，数据库层面事务回滚依赖的是undo sql脚本，业务层面事务回滚依赖的是自己写补偿代码，用户在选择分布式事务模式时需要兼并考虑代码的侵入性和长事务性能问题。目前看，XA事务模型由于其性能最差，实际项目用的很少了；AT事务模型无代码侵入，性能较好，在交易类业务系统（比如：ERP、MES、CRM等）中推荐使用；TCC事务模型虽然性能最好，但需要写代码，且需要结合业务设计，非高并发项目谨慎使用；SAGA模型最复杂，没有特殊需求，不推荐使用。
参考：