分布式事务—＞ seata

分布式事务之Seata

一、什么是分布式事务？

分布式事务是一种特殊类型的事务，它涉及多个分布式系统中的节点，包括事务的参与者、支持事务的服务器、资源服务器以及事务管理器。

在分布式事务中，一次大型操作通常由多个小操作组成，这些小操作分布在不同的服务器上，并且属于不同的应用。分布式事务的关键在于确保这些小操作要么全部成功，要么全部失败，以保持数据的一致性。这种事务模型主要用于确保不同数据库或系统之间的数据一致性。

分布式事务管理通常面临一些独特的挑战，例如确保所有参与系统的事务日志之间的一致性，以及处理网络延迟或断连的情况。实现分布式事务通常需要复杂的协调机制，以确保在发生故障时仍能维护数据的完整性

二、那么为什么要使用分布式事务呢？

由于近十年互联网的发展非常迅速，很多网站的访问量越来越大，集中式环境已经不能满足业务的需要了，只能按照业务为单位进行数据拆分（包含：垂直拆分与水平拆分），以及按照业务为单位提供服务，从早期的集中式转变为面向服务加构的分布式应用环境。
举一个经典的例子，阿里的淘宝网站随着访问量越来越大，只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分，以及按照业务为单位提供服务接口。这个时候，为了完成一个简单的业务功能，比如：购买商品后扣款，有可能需要横跨多个服务，涉及用户订单、商品库存、支付等多个数据库，而这些操作又需要再同一个事务中完成，这就涉及到了分布式事务。
本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。

三、事务的ACID原则

所有的事务必须满足ACID原则

四、分布式的一致性理论

最早加州大学伯克利分校Eric Brewer教授提出一个分布式系统特性的CAP理论。

1、CAP理论的不可能三角

1. 一致性（Consistency）
2. 可用性（Availability）
3. 分区容错性（Partition tolerance）

在分布式系统中，是不存在同时满足一致性Consistency、可用性Availability和分区容错性Partition Tolerance三者的。

一句话总结：一致性、可用性和分区容错再分布式事务中不可兼得。再绝大多数的场景，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。
这也是后来发展出来的BASE理论的基础

2、BASE理论

1. Basically Available（基本可用）
2. Soft State（柔软状态）
3. 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一阶段的工作：

1. 注册分支事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC

TC二阶段的工作：

TC检测各分支事务执行状态

• 如果都成功，通知所有RM提交事务
• 如果有失败，通知所有RM回滚事务

RM二阶段的工作：

• 接收TC指令，提交或回滚事务

XA模式的优势：

事务具备强一致性(满足ACID原则)、比较容易实现分布式事务的效果，常用的数据库都支持，无代码侵入

缺点：

因为一阶段需要锁定数据库资源，要等到二阶段结束才能释放，容易造成资源的浪费，性能较差，需要依赖关系型数据库实现事务

5.2、AT模式原理

AT模式同样是分阶段提交的事务模型，不过却弥补了XA模式中资源锁定周期过长的缺陷。

阶段一RM的工作：

1. 注册分支事务
2. 记录undo-log(数据快照)
3. 执行业务sql并提交
4. 报告事务状态

阶段二提交时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能有一个更深次的理解！