这是我参与11月更文挑战的第4天，活动详情查看：2021最后一次更文挑战
Saga模式
Saga模式称为长事务解决方案，它主要描述在没有两阶段提交的情况下，核心思想是把一个业务流程中的长事务拆分为多个本地短事务，业务流程中的每个参与者都提交真实的提交给该本地短事务，当其中一个参与者事务执行失败时，则通过补偿机制补偿已陈工的参与者。
Saga是由一系列sub-transaction Ti组成，每个Ti都有对应的补偿动作Ci,补偿操作作用于撤销Ti造成的数据变更结果，它和TCC相比，少了Try这个预留动作，每一个Ti操作都真实地影响数据库。
按照Saga的工作模式，有两种执行方式。
- T1、T2、T3...Ti这种方式表示所有事务都正常执行
- T1、T2....，Ti,C1...Cj（0<j<i）这种方式表示执行到Ti事务时出现异常，通过补偿操作撤销之前所有成功的sub-transaction
Saga提供了以下两种补偿恢复方式
- 向后恢复，就是提到第二种工作模式，如果任一子事务执行失败，则把之前执行逐一撤销
- 向前恢复，就是不进行补偿，而是对失败的事务进行重试，这种方式比较适合于事务必须要执行成功的场景。
不论是向后恢复还是向前恢复，都可能出现失败的情况，在最坏情况下只能人工干预事务。
Saga优缺点
和XA或者TCC相比，它的优点是一阶段直接提交本地事务，没有锁等待，性能较高，在事件驱动模式下，短事务可以异步进行，补偿机制的实现比较简单。
缺点：Saga并不提供原子性和隔离性支持，隔离性的影响是比较大的，比如用户购买一个商品后系统赠送一张优惠券，如果用户已经把优惠券使用了，那么事务如果出现异常要回滚时就会出现问题。
