Seata-Saga模式

Saga事务模式相对来说是最复杂的，用的不多，只需要把概念理解透就可以了。

Saga是Seata提供的长事务解决方案，在业务流程中每个参与者都提供本地事务，当出现某个参与者失败的情况则补偿前面已经成功的参与者。

Saga也是二阶段的提交，一阶段是正向服务，二阶段是补偿服务，补偿机制就是执行的时候出错了，给它一个改正的机会。

一阶段正向执行，比如T1和T2正常，T2到T3也正常，T3位置出现问题了， 就需要整体的回滚，这个时候就会进行反向补偿，把之前的已成功的状态都补偿回去。

Saga模式下的分布式事务通常是由事件驱动完成的，各个参与者之间是异步执行的。

XA和AT都是数据源代理，业务侵入型少；TCC是自己实现业务逻辑（实现Try、Confirm、Cancel接口），业务侵入性强；而Saga应用场景：封闭式老系统无法修改同时也没有引入任何分布式事务

比如这3个项目之间的分布式事务问题需要引入Seata的Saga模式，对于不能修改业务代码的场景，只能通过外部的方式来实现分布式事务。

Saga提供了异构系统的事务统一处理模型，保障了整个系统的分布式事务。

所有的子业务系统都不能参与整体的事务处理，比如java项目只负责自身的本地事务处理。

本地事务完成之后，全部交由调用端来进行处理。

在进行总业务处理时，如果某一个子业务出现了问题，则自动补偿前面已经执行成功的其他参与者。

一阶段的正向服务调用和二阶段的事务补偿处理全部由总业务开发实现。

在Saga模式下，子系统业务有对应的业务处理接口和业务补偿接口。

Saga业务模型用json文件来进行管理，调用子业务处理的时候，一阶段的情况下远程调用子业务系统提供的接口。

调用子业务系统的时候，调用对应的接口进行本地的事务处理，如果没有问题，则调用第二个，都没有问题的话，整体提交。

如果第二个出现了问题，则调用二阶段业务补偿接口，即数据回滚接口。

一阶段没有问题，则继续执行，如果有一个子业务系统有问题，就会调用二阶段的业务补偿接口来进行数据的回滚处理，这是对应Saga处理的事务模型。

通过Saga的状态机来完成总业务的处理，需要开发者进行手工的业务流程的绘制并将其转换成json的配置文件，在程序运行时，将依据配置文件实现业务处理以及服务补偿处理 。

要进行Saga的状态绘制，一般通过Saga状态机实现，通过状态图来定义服务间调用流程。

比如图1中这3个完全没有关系的服务，在总业务逻辑处理的时候，使用Saga的状态机来定义，调用服务1，再调用服务2，再调用服务3。状态图中的每一节点可以调用一个服务，也可以配置它的补偿节点。

状态图的json是由状态机的引擎驱动执行，当出现异常时，状态反向执行已成功的节点对应的补偿节点将事务回滚。

每一个子服务里面都会配置一个业务接口和一个业务补偿接口，当出现问题了，就会调用业务补偿接口向上补偿。

Saga状态机可以完成整个服务的编排需求、支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等。

Seata中的Saga事务模式是由外部的Saga提供的状态机来进行完成的，需要定义总流程，状态机里可以定义当前节点的调用服务，而且每个节点上可以配置当前这个调用服务的反向补偿节点。

当某一节点出现问题的时候，就会调用向上的反向补偿。

最开始的时候由业务负责本地的事务处理，当本地的事务处理出现问题的时候，会调用当前的反向补偿接口，然后再向上补偿。