微服务分布式事务解决方案-开源软件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模型最复杂，没有特殊需求，不推荐使用。
​
 参考：
https://seata.apache.org/blog
http://www.yunchengxc.com/
​

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。