Seata系列之入门_seata快速入门

Seata，一个开源的分布式事务解决方案的框架，主旨是在微服务架构下提供高性能和简单易用的分布式事务服务，并且提供了AT、TCC、Saga和XA事务模式，提供了一站式的分布式事务解决方案，其中TCC和XA我之前的一片文章有写过：

分布式事务系列之入门_codain的博客-CSDN博客分布式事务系列之入门https://blog.csdn.net/qq_38377525/article/details/123159026分布式事务系列之常见解决方案_codain的博客-CSDN博客分布式事务系列之常见解决方案https://blog.csdn.net/qq_38377525/article/details/123203672那么我们讲一下AT和Saga这两种事务模式

---

1、AT模式

这个模式是Seata最主推的分布式事务解决方案，他是基于XA演变而来的一种分布式事务模式，所以同样的它分为三大模块，分别是TM、RM和TC，其中TM和RM是作为Seata的客户端与业务系统的集成，TC作为Seata的服务器独立部署，TM表示事务管理器，他负责向TC注册一个全局事务，并生成一个全局唯一的XID，在这个模式下，每个数据库被当做为一个RM，在业务层面通过JDBC标准的接口访问RM时，Seata会对所有请求进行拦截，每个本地事务进行提交时，RM都会向TC注册一个分支事务，模式如图：

 看图说流程：

• TM向TC注册全局事务，并生成全局唯一的XID
• RM向TC注册分支事务，并将其纳入该XID对应的全局事务范围
• RM向TC汇报资源的准备状态
• TC汇总所有事务参与者的执行状态，决定分布式事务是全部回滚还是提交
• TC通知所有RM提交/回滚事务

---

2、Saga模式

Saga模式又叫长事务解决方案，主要描述的是在没有两阶段提交的情况下如何解决分布式事务问题，核心思想是：把一个业务流程中的尝试无拆分为多个本地短事务，业务流程中的每个参与者都提交真实的提交给该本地短事务，当其中一个参与者事务执行失败，则通过补偿机制补偿前面已经成功的参与者，上图：

上图可以知道，Saga是由一系列的Tn组成，每个Tn都有对应的Cn补偿动作，补偿动作用于撤销Tn造成的数据变更结果，它和TCC相比，少了Try这个预留动作，每个Tn操作都真实的影响到数据库

按照Saga的工作模式，他有两种执行方式：

1、T1、T2、T3....，Tn：这种方式标识所有的事务都是正常执行的

2、 T1、T2、T3....，Tj，Cj....，C2，C1：这种表示在Tj这个事务出现了异常，会通过Cn补偿操作撤销之前所有成功的T

Saga还提供了以下两种补偿恢复方式：

1、向后恢复：就是上面提到的第二种工作模式，如果有任意一个事务执行失败了，就会把之前所有的执行全部撤销掉

2、向前恢复：就是不进行补偿，对失败的事务进行重试，这种方式比较适合事务必须要执行成功的场景

这两种补偿方式，其实都有可能出现失败的情况，实在不行的时候，就只能人工干预的去处理相关的操作和数据了

Saga的优劣势：

优势：优势是对比XA和TCC体现的，一阶段直接提交本地事务，没有锁等待，性能较高，在时间驱动的模式下，短事务可以异步执行，补偿机制的实现比较简单

缺点：它不提供原子和隔离性，尤其是隔离性的影响，对系统来说是比较大的 

Saga的实现方式：

电商平台下单是一个典型的长事务场景(看下图)，

根据Saga模式的说法，要先将长事务拆分成多个本地短事务，每个服务的本地事务按照执行顺序逐一提交，一旦有一个事务异常了，则会采用补偿的方式进行撤回，这一过程的实现就要提到Saga的协调模式了：

---

• 事件/编排式：把Saga的决策和执行顺序逻辑分布到Saga的每一个参与者中，他们通过交换事件的方式来进行沟通

在基于事件的编排模式中，第一个服务执行完一个本地事务之后，会发送一个事件或者指令，这个指令会被多个服务监听，监听到指令的服务在执行本地事务并发布新指令，然后一直延续这种指令的触发模式，直到当前业务流程中最后一个服务的本地事务执行结束，才能说整个分布式事务执行完成

咱们简单说一下订单支付的问题来体验一下：

①订单服务创建一个新订单，把订单状态设置为待支付，并发布一个创建订单的事件

②库存服务监听到创建订单的事件后，会执行本地的库存冻结方法，如果执行成功了，就会发布一个库存冻结的事件

③支付服务监听库存冻结的时间后，会执行账户扣减方法，并发布支付订单的事件

④积分服务监听支付订单的事件之后，增加账户积分，并更新订单状态为支付成功

需要注意的是，上面的步骤中的所有事务，但凡有一个失败，就会全部回滚

---

• 命令/协同式：把Saga的决策和执行顺序逻辑集中在一个Saga控制类中，它以命令/回复的方式与每项服务进行通信，告诉对应的服务需要执行哪些操作 

需要定义一个Saga协调器，专门负责每个参与者该做什么，Saga协调器以命令/回复的方式与每项服务进行通信，咱们再结合电商案例去体会提下：

①订单服务会先创建一个订单，然后创建一个订单Saga协调器，启动订单事务

②Saga协调器会向库存服务发送冻结库存命令，库存服务通过上图中的Order Saga Reply Queue回复执行结果

③然后协调器继续向支付服务发起账户扣款指令，支付服务通过Order Saga Reply Queue回复执行结果

④最后协调器会向积分服务发起增减积分指令，积分服务同时也会返回执行结果

需要注意的是，订单协调器必须提前知道"创建订单"的所有流程，因为Seata是通过基于JSON的状态引擎来实现的，并且在任何一个环节失败了，它都会向每个参与者发送回滚事务的操作