Saga定义
Saga模式是一种分布式事务处理模式，用于保证分布式系统中的一系列操作要么全部成功执行，要么全部回滚，以实现一致性的目标。它采用了长事务的概念，将原子操作拆分为多个子事务，并通过补偿机制保证整个事务的一致性。
Saga是一种比较传统的解决方案，传统的业务系统中通常会提供冲正服务，当正向服务执行失败时，业务会自动调用冲正服务，将已经发生变化的数据再修改回去，这种解决思想与Saga相同。
Saga组成
Saga由一个个独立的本地事务组成（T1，T2，T3...），并且每个独立的本地事务提供反向逻辑（C1，C2，C3...），反向逻辑是指正向节点发生的变化会滚回去，如T1将数据ID=1 变更为ID=2，则反向逻辑是将ID变更为ID=1
T3节点执行失败，则开始执行冲正服务C2->C1。
Saga隔离性问题
事务隔离性
事务隔离性（Isolation）指的是一个事务的执行过程不会被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的。这意味着并发执行的各个事务之间不能互相干扰，每个事务都独立地在自己的工作空间内完成，并且其结果在事务未提交之前对其他事务是不可见的。
事务隔离级别
事务隔离级别存在以下四种
-
读已提交
- 事务内读取的是别的事务已经提交的数据，能够防止脏读，但是无法限制不可重复读和幻读。
-
读未提交
- 能够读取到没有被提交的数据，这个级别的隔离机制无法解决脏读、不可重复读、幻读中的任何一种。
-
可重复读
- Mysql数据库默认隔离级别，一个事务内支持多次读取相同的数据，即第一次读取和第二次读取相同。
-
串行化
- 最严格的隔离级别，操作相同的数据全部加锁以串行的方式执行，数据安全性最高，但是性能上有严重的不足。
Saga隔离性
Saga这种模式对隔离性没有处理，每个本地事务提交，影响的数据对其他事务可见，如下场景
当Saga1流程中的T1执行成功后，本地事务提交，此时执行Saga2流程对ID=1的数据进行了更新ID=2，当Saga1流程执行T2失败后，调用C1进行冲正，此时如何处理？如果直接将ID更新为1，则丢失其他事务修改后的数据。
Saga隔离性问题处理
-
第一种解决思路
- 如果开发过程中分析业务场景可能存在这种问题，流程执行过程中记录为特殊节点，特殊节点执行过后不允许执行冲正执行，重试正向服务中的节点，这样即使数据被其他事务修改，也无影响。
-
第二种解决思路
- 通过分布式锁解决，事务执行前对操作的数据进行加锁，节点T执行成功后不释放锁，需要等待Saga流程全部执行结束后释放锁，这种方案存在明显的问题的是降低了并发能力，因为锁的持有时间是与整个Saga流程时间相同。