企业官网建设流程全解析

中国招投标网站官网,珠海建网站的联系方式,灌云住房和城乡建设网站,阿里云网站建设考试本文总结#xff1a;本文探讨了分布式事务的概念及解决方案。分布式事务指在分布式系统中多个服务协同完成业务时#xff0c;需确保各服务事务同时成功或失败。针对这一问题#xff0c;文章分析了多种解决方案#xff1a;1#xff09;2PC/XA协议采用强一致性#xff0c;通…本文总结本文探讨了分布式事务的概念及解决方案。分布式事务指在分布式系统中多个服务协同完成业务时需确保各服务事务同时成功或失败。针对这一问题文章分析了多种解决方案12PC/XA协议采用强一致性通过两阶段提交实现2Seata的AT模式利用快照实现最终一致性3TCC模式通过Try-Confirm-Cancel三阶段处理事务4消息队列方案通过异步消息保证最终一致5Saga模式适用于长流程业务。选择方案时应根据业务需求在强一致性和最终一致性间权衡大多数场景可采用最终一致性方案。分布式事务分布式事务是什么呢在分布式系统中如果一个业务需要多个服务合作一起完成并且每个服务都有事务然后多个事务必须要同时成功或同时失败这就是分布式事务。分布式事务问题多个服务之间各执行各的比如下图用户执行下单支付操作下单支付成功则购物车商品清空成功这时假如我们的库存本来就是0库存不足那库存扣减就会失败。也就是说下单服务和购物车服务都执行成功了而库存执行失败那这整个业务就出问题了只有前两个服务数据改变最后一个不变这就是分布式事务的问题。解决思想就是要让各个服务能感知到彼此的事务状态是否一致解决分布式事务问题可以使用Seata提供的各种解决方案。TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态驱动全局事务提交或回滚。TM (Transaction Manager) - 事务管理器定义全局事务的范围开始全局事务、提交或回滚全局事务。RM (Resource Manager) - 资源管理器管理分支事务处理的资源与TC交谈以注册分支事务和报告分支事务的状态并驱动分支事务提交或回滚。有两种根本思路1、强一致性上帝视角进行指挥2、最终一致性事后约定进行补救分布式事务解决方案介绍方案A2PC/XA协议强一致性例子现场投票表决全员举手才能通过。第一阶段准备投票协调者总指挥问订单系统“能创建订单吗” 订单系统创建订单但不提交回复“可以。”同样问购物车、库存系统都预执行并回复“可以”。第二阶段提交/回滚宣布结果如果全部回复“可以”协调者下令“全体正式提交”如果任何一个回复“不行”协调者下令“全体回滚撤销”方案BSeata中的AT模式最终一致性例子投票时先拍照存底一旦失败就按照片复原。第一阶段拍照预执行每个系统在本地直接提交业务但同时拍下数据修改前的“快照”存入undo_log表。第二阶段成功总指挥说成功大家把“快照”删掉即可。失败总指挥说失败大家根据undo_log里的“快照”自动执行反向SQL把数据恢复原样。XA模式和AT的区别1、XA模式第一阶段不提交事务锁定资源AT模式第一阶段就直接提交不锁定资源。2、XA模式依赖于数据库机制事务回滚而AT是基于快照进行回滚的3、XA模式强一致性AT模式最终一致性方案CTCC模式最终一致性TCC模式初衷是强一致性但可能会因为网络延迟、服务中断等外部因素问题使它几乎不可能是强一致性不得不降为最终一致性。还是以订单服务---购物车服务---库存服务为例。“预备、确认、取消”三步骤这不是自动的需要你为每个系统写三个方法1、Try尝试/预备冻结资源而非真正扣除。订单系统订单状态置为“待确认”。购物车系统锁定冻结购物车真实购物车商品数不变。库存系统对应商品预扣-1标记为“待生效”。2、Confirm确认Try都成功才真正执行。订单系统状态变“成功”。购物车系统清空已冻结的购物车商品。库存系统将预扣商品变为“有效”。3、Cancel取消任何一个Try失败则释放资源。订单系统状态变“已取消”。购物车系统释放冻结的购物车商品。库存系统清除预扣减的库存。TCC模式总结性能好隔离性强。但侵入性极大需要写三倍代码并且要处理幂等、空回滚等复杂问题。适用于金融、库存等严格要求的情景。方案D基于消息队列最终一致性例子发短信通知直到对方确认为止。核心是依靠可靠的消息传递来驱动下游事务。流程1、订单系统和购物车系统在同一个数据库事务中完成并同时向消息队列写入一条“订单已创建请扣减库存”的消息或插入本地消息表。2、事务提交。3、消息队列保证把消息送达库存系统。4、库存系统消费消息为扣减商品数量。如果失败消息队列会重试。关键消息的可靠存储和可靠投递。库存服务需要幂等设计防止因重试导致库存扣减多次。消息队列总结彻底解耦高性能高可用。但只保证最终一致性设计时重点考虑消息可靠性、消费者幂等。方案ESaga模式最终一致性例子执行一个长长的清单任何一步失败就倒着往回取消。适合流程非常长分钟/小时级的业务比如快递订机票、酒店。流程1、订单系统 - 成功。2、库存系统 - 成功。3、调用外部物流系统安排配送 -失败补救立即启动“反向操作”流程1、执行库存系统的补偿逻辑回滚扣减。2、执行订单系统的补偿逻辑取消订单。Saga总结性能极高适合长流程。但补偿逻辑设计复杂且缺乏隔离性可能脏读需要业务能够容忍。如何进行分布式事务解决方案选择一句话总结就是XA/2PC强一致但性能差仅用于传统银行核心TCC模式高性能最终一致适用于金融、库存等需要资源预留的场景AT模式无侵入最终一致适合大多数普通业务Saga模式长流程最终一致适合旅行预订、保险理赔消息队列异步最终一致适合通知、数据同步等解耦场景核心原则99%的业务场景都可以接受最终一致性因此分布式事务的重点不是追求强一致而是在接受最终一致的前提下根据具体业务特点选择最合适的方案。