分布式事务(四)：Seata之Saga事务模式原理
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
Seata2.x提供的Saga是基于状态机引擎实现的，下面来看看状态机引擎。
1、状态机引擎机制
1、通过状态图来定义服务调用的流程生成json状态语言定义文件；
2、状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点；
3、状态图json由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚 （异常发生时是否进行补偿可由用户自行决定）
4、可以1实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等
2、状态机引擎原理
·以上状态图先执行stateA, 再执行stateB，然后执行stateC；
·"状态"的执行是基于事件驱动的模型，stateA执行完成后，会产生路由消息放入EventQueue，事件消费端从EventQueue取出消息，执行stateB；
·在整个状态机启动时会调用Seata Server开启分布式事务，并生产xid, 然后记录"状态机实例"启动事件到本地数据库；
·当执行到一个"状态"时会调用Seata Server注册分支事务，并生产branchId, 然后记录"状态实例"开始执行事件到本地数据库；
·当一个"状态"执行完成后会记录"状态实例"执行结束事件到本地数据库, 然后调用Seata Server上报分支事务的状态；
·当整个状态机执行完成, 会记录"状态机实例"执行完成事件到本地数据库, 然后调用Seata Server提交或回滚分布式事务。
3、状态机引擎设计
状态机引擎的设计主要分成三层, 上层依赖下层，从下往上分别是：
3.1、Eventing 层
实现事件驱动架构, 可以压入事件, 并由消费端消费事件, 本层不关心事件是什么消费端执行什么，由上层实现
3.2、ProcessController 层
由于上层的Eventing驱动一个“空”流程引擎的执行，"state"的行为和路由都未实现, 由上层实现
基于以上两层理论上可以自定义扩展任何"流程"引擎
3.3、StateMachineEngine 层
实现状态机引擎每种state的行为和路由逻辑
提供 API、状态机语言仓库
4、状态机的高可用
状态机引擎是无状态的，它是内嵌在应用中。
4.1、应用正常运行
图中上半部分表示；
状态机引擎会上报状态到Seata Server；
状态机执行日志存储在业务的数据库中。
4.2、某台应用实例宕机
图中下半部分表示；
Seata Server 会感知到，并发送事务恢复请求到还存活的应用实例；
状态机引擎收到事务恢复请求后，从数据库里装载日志，并恢复状态机上下文继续执行。
