网站后台怎么上传文件,wordpress谷歌慢,山西设计网站建设,海南网页seata
前两篇文中总结了一下分布式事务已经现阶段常用的解决方案#xff0c;现在来讨论一下现有的分布式事务框架seata#xff0c;点击此处是seata的官网seata致力于微服务框架下提供高性能和简单易用的分布式事务服务。它提供了AT#xff0c;TCC#xff0c;Saga #xf…seata
前两篇文中总结了一下分布式事务已经现阶段常用的解决方案现在来讨论一下现有的分布式事务框架seata点击此处是seata的官网seata致力于微服务框架下提供高性能和简单易用的分布式事务服务。它提供了ATTCCSaga XA这几种事务模型为开发者提供了一站式的分布式事务解决方案。其中TCC和XA我们上一篇文中已经有说明接下来我们讨论一下Seata中AT和Saga这两种事务模型是怎么样的。
AT模式
AT模式是Seata最主推的分布式事务解决方案他是基于XA演进过来的一种分布式事务模式随意他同样分为三大模块分别是TMTransaction ManagerRMResource Manager和TCTransaction Server其中TM和RM作为Seata客户端与业务系统集成TC作为Seata的服务器端独立部署TM表示事务管理器他负责向TC注册一个全局事务并生成一个全局事务唯一XID。在AT模式下每个数据库资源被称作一个RM在业务层通过JDBC标准接口范问RM的时候Seata会对所有请求进行拦截。每一个本地事务进行提交时候RM都会想TC事务协调器注册一个分支事务。Seata的AT模式如下图说明 具体流程如下 TM向TC注册一个全局的事务并生成全局XID期间整个业务流程内每个RM想TC注册分支事务并将其纳入改XID对应的全局事务范围RM想TC汇报资源的准备状态TC汇总所有事务参与者的状态决定分布式事务是全部回滚还是全部提交TC通知所有RM提交/回滚事务 AT模式和XA模式一样都是一个两阶段提交的事务模型不过和XA相比做了一些优化这个官网着重讲解了一下AT的原理之后开一节着重看下一AT模式的实现原理。
Saga模式 Saga模式是SEATA提供的长事务解决方案这种理论模型是由普林斯顿大学的Hector Garcia-Molina 和 Kenneth Salem 提出的主要描述的是在没有两阶段提交的前提下如何解决分布式事务问题。核心思想是将一个业务流程中长事务拆分为多个本地的短事务业务流程中每个参与者都提交正式的提交给本地短事务当其中一个参与者事务执行失败则通过补偿机制补偿签名已经成功的参与者。 如下图说明Saga由一系列sub-transaction Ti 组成每个Ti 都有对应的补偿动作Ci 补偿动作用于撤回Ti 造成的数据变化。和TCC相比少了Try这一步每个操作都是真实的数据库操作。 按照Saga的工作模式有两种执行方式 T1 T2 T3 …Ti: 这种方式表示所有事务都正常执行。T1 T2 … TjCj…C2C1 这种情况是表示执行到Tj的时候Tj 事务出现异常通过补偿操作撤销之前所有成功的sub-transaction 另外Saga还提供了一下两种补偿恢复方式 向后恢复也就是上面提到的第二中工作模式如果任何一个子事务执行失败则吧之前执行的结果逐个撤销向前恢复也就是不进行补偿而是对失败的事务进行重试这种方式比较适合事务必须要执行成功的场景。
Saga的优势
和XA和TCC比较他的优势包括一阶段直接提交本地事务没有锁没有锁没有锁性能较高在事件驱动的模式下段事务可以异步执行补偿机制的实现比较简单。缺点是Saga并不提供原子性和隔离性支持隔离性的影响是比较大的比如用户购买一个情感课程后会赠送一段时间会员或者赠送打折卷如果用户在回滚之前将优惠券用掉了会在在回滚之前使用了会员的一些特殊服务那么事务出现异常回滚的时候就无法收回这部分会出现业务上的问题。
Saga的实现方式 就像刚才的案例用户购买情感课程这个业务场景下会涉及到订单创建课程库存的修改微信支付会员赠送整个流程如下 在以上支付下单的流程上一个典型的长事务根据Saga模式的定义先将长事务拆分成对个本地端事务每个服务的本地事务按照执行顺序逐一提交一旦其中一个服务的事务出现异常则采用补偿的方式逐一撤回。这一过程的实现会设计Saga的协调模式他有两种常用的协调模型。 事件/编排式把Saga的决策和执行顺序逻辑分布在Saga的每一个参与者中他们通过交换事件的方式来进行沟通命令/协同式把Saga的角色和执行顺序逻辑集中在一个Saga控制类中他以命令/回复的方式与每一项服务进行通信告诉他们应该执行哪个操作。
事件/编排式
在基于时间的编排模式中第一个服务执行完一个本地事务之后发送一个事件。这个事件会被一个或者多个服务监听监听到事件的服务接着执行他自己的本地事务并发布新的事件此后一直延续这种事件触发模式直到整个业务流程中最后一个服务的本地事务执行结束才意味着整个分布式长事务也执行结束。我们用如下图说明 如上图流程看起来复杂但是他是比较常见的解决方案解释以上流程 订单服务创建新的订单吧订单状态设置为待支付并发布一个“创建订单”事件库存服务监听到 “创建订单”事件后执行本地库存冻结方法如果执行成功则发布一个“库存准备事件”支付服务监听到 “库存准备事件”事件后执行账户扣款方法并发布 “支付事件”最后积分服务监听到“支付事件”事件后增加账户积分并更新订单状态为成功 如果上述任何一次执行失败当前时间都变成失败的时间例如“库存准备事件” 变成 “库存准备失败事件”每个服务需要监听失败的情况根据实际需求进行逐一回滚。
命令/协同式
命令/协同 模式需要定义一个Saga协调器负责告诉每一个参与者该做啥。Saga协调器以命令/回复的方式与每一个服务进行通信如下流程 命令协同模式流程如下 订单服务手下创建一个订单然后创建一个订单的协调器用来协调之后的事务启动订单事务。Saga协调器向库存服务发送冻结库存命令库存服务通过订单 Saga回复队列回复直接的结果接着Saga协调器继续向支付服务发起咋呼扣款命令支付服务通过订单 Saga回复队列回复执行结果最后Saga协调器向会员服务发起添加会员命令会员服务回复执行结果。 整个流程需要有一个前置条件订单Saga协调器必须提前知道“创建订单事务”的所有流程并且在整个流程中任何一个环节执行失败他都需要向每个参与者发送命令撤销之前的事务操作。
上一篇分布式事务解决方案 下一篇分布式事务 – seata框架AT模式实现原理
