宜兴建设局网站,网站开发程序介绍,建立网站准备工作流程,学做网站最好的网站分布式事务之Seata
一、什么是分布式事务#xff1f;
分布式事务是一种特殊类型的事务#xff0c;它涉及多个分布式系统中的节点#xff0c;包括事务的参与者、支持事务的服务器、资源服务器以及事务管理器。
在分布式事务中#xff0c;一次大型操作通常由多个小操作组成…分布式事务之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 组织定义的分布式事务处理(DTPDistributed 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能有一个更深次的理解
