本文主要是介绍分布式事务—＞ seata，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
分布式事务之Seata
一、什么是分布式事务？
分布式事务是一种特殊类型的事务，它涉及多个分布式系统中的节点，包括事务的参与者、支持事务的服务器、资源服务器以及事务管理器。
在分布式事务中，一次大型操作通常由多个小操作组成，这些小操作分布在不同的服务器上，并且属于不同的应用。分布式事务的关键在于确保这些小操作要么全部成功，要么全部失败，以保持数据的一致性。这种事务模型主要用于确保不同数据库或系统之间的数据一致性。
分布式事务管理通常面临一些独特的挑战，例如确保所有参与系统的事务日志之间的一致性，以及处理网络延迟或断连的情况。实现分布式事务通常需要复杂的协调机制，以确保在发生故障时仍能维护数据的完整性
二、那么为什么要使用分布式事务呢？
由于近十年互联网的发展非常迅速，很多网站的访问量越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分（包含：垂直拆分与水平拆分），以及按照业务为单位提供服务，从早期的集中式转变为面向服务加构的分布式应用环境。
举一个经典的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。这个时候，为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要再同一个事务中完成，这就涉及到了分布式事务。
本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。
三、事务的ACID原则
所有的事务必须满足ACID原则
四、分布式的一致性理论
最早加州大学伯克利分校Eric Brewer教授提出一个分布式系统特性的CAP理论。
1、CAP理论的不可能三角
- 一致性（Consistency）
- 可用性（Availability）
- 分区容错性（Partition tolerance）
在分布式系统中，是不存在同时满足一致性Consistency、可用性Availability和分区容错性Partition Tolerance三者的。
一句话总结：一致性、可用性和分区容错再分布式事务中不可兼得。再绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。
这也是后来发展出来的BASE理论的基础
2、BASE理论
- Basically Available（基本可用）
- Soft State（柔软状态）
- Eventually consistent（最终一致性）
BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的结论，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency）
，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）
五、Seata架构
Seata事务管理中有三个重要的角色：
TC(Transaction Coordinator)-事务协调者:维护全局和分支事务的状态，协调全局事务提交或回滚。
TM(Transaction Manager)-事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
RM(Resource Manager)-资源管理器:管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata提供了四种不同的分布式事务解决方案
- XA模式:强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
- TCC模式:最终一致的分阶段事务模式，有业务侵入
- AT模式:最终一致的分阶段事岛模式，无业务侵入，也是Seata的默认模式
- SAGA模式:长事务模式，有业务侵入
5.1、XA模式原理
XA规范 是X/0pen 组织定义的分布式事务处理(DTP，Distributed Transaction Processing)标准，XA规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA规范 提供了支持。
分为两个阶段：
第一阶段：
第二阶段：
seata的XA模式做了一些调整，但大体相似： 
RM一阶段的工作：
- 注册分支事务到TC
- 执行分支业务sql但不提交
- 报告执行状态到TC
TC二阶段的工作：
TC检测各分支事务执行状态
- 如果都成功，通知所有RM提交事务
- 如果有失败，通知所有RM回滚事务
RM二阶段的工作：
- 接收TC指令，提交或回滚事务
XA模式的优势：
事务具备强一致性(满足ACID原则)、比较容易实现分布式事务的效果，常用的数据库都支持，无代码侵入
缺点：
因为一阶段需要锁定数据库资源，要等到二阶段结束才能释放，容易造成资源的浪费，性能较差，需要依赖关系型数据库实现事务
5.2、AT模式原理
AT模式同样是分阶段提交的事务模型，不过却弥补了XA模式中资源锁定周期过长的缺陷。
阶段一RM的工作：
- 注册分支事务
- 记录undo-log(数据快照)
- 执行业务sql并提交
- 报告事务状态
阶段二提交时RM的工作：
- 删除undo-log即可
阶段二回滚时RM的工作：
- 根据undo-log恢复数据到更新前
下面这张图片更利于理解
那么AT模式与XA模式最大的区别是什么?
- XA模式一阶段不提交事务，锁定资源;AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚;AT模式利用数据快照实现数据回滚。
- XA模式强一致;AT模式最终一致
AT模式会有问题——>脏写| 使用全局锁的方式解决(AT模式的写隔离)。全局锁：由TC记录当前正在操作的某行数据的事务，该事务持有全局锁，具备执行权
AT模式的优点
- 一阶段完成直接提交事务，释放数据库资源，性能比较好
- 利用全局锁实现读写隔离
- 没有代码侵入，框架自动完成回滚和提交
AT模式的缺点:
- 两阶段之间属于软状态，属于最终一致
- 框架的快照功能会影响性能，但比XA模式要好很多
5.3、TCC模式原理
TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法。
- Try:资源的检测和预留。
- Confirm:完成资源操作业务:要求Try成功 Confirm 一定要能成功。
- Cancel:预留资源释放，可以理解为try的反向操作。
举例：一个扣减用户余额的业务。假设账户A原来余额是100，需要余额扣减30元。
阶段一(Try)：检查余额是否充足，如果充足则冻结金额增加30元，可用余额扣除30
阶段二(Confirm)：假如要提交(Confirm)，则冻结金额扣减30
阶段二(Cancel)：如果要回滚(Cancel)，则冻结金额扣减30，可用金额增加30
整体工作模型：
5.3.1、TCC模式的每个阶段是做什么的?
- Try:资源检查和预留
- Confirm:业务执行和提交
- Cancel:预留资源的释放
5.3.2、TCC的优点是什么?
- 一阶段完成直接提交事务，释放数据库资源，性能好
- 相比AT模型，无需生成快照，无需使用全局锁，性能最强
- 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库
5.3.3、TCC的缺点是什么?
- 有代码侵入，需要人为编写try、Confirm和Cancel接口，太麻烦
- 软状态，事务是最终一致
- 需要考虑Confirm和Cancel的失败情况，做好幂等处理
TCC模式会出现的问题：空回滚和业务悬挂
空回滚：
当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时cancel不能做回滚，这就是空回滚
业务悬挂：
对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂
为了实现空回滚、防止业务悬挂，以及幂等性的要求。我们必须在数据库记录冻结金额的同时，记录当前事务id和执行状态，为此我们设计了一张表：
业务分析：
5.4、Saga模式
Saga模式是Seata提供的长事务解决方案。也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
Saga模式优点：
- 事务参与者可以基于事件驱动实现异步调用，吞吐高
- 一阶段直接提交事务，无锁，性能好
- 不用编写TCC中的三个阶段，实现简单
缺点：
- 软状态持续时间不确定，时效性差
- 没有锁，没有事务隔离，会有脏写
Saga模式的使用是较少的，适合使用业务跨度比较大的场景，如：跨银行的一些业务调用、转账等，业务比较复杂的场景，大多数情况下使用不到的。
六、四种模式对比：
到这里就结束啦，希望小伙伴看完之后对分布式事务Seata能有一个更深次的理解！
这篇关于分布式事务—＞ seata的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
