分布式事物SAGA

目录

• 概述SAGA
• SAGA的执行方式
  • 存在的问题
  • 重试机制
• SAGA VS TCC
• 实现SAGA的框架

概述SAGA

SAGA是1987 Hector & Kenneth 发表的论文，主要是解决长事务执行的问题。有的系统比较旧同时也需要长事物，不能改造，那么比较适用这种场景处理，还有金融行业比较适合用这种事务，主要也是流程会比较长。

SAGA的执行方式

SAGA是两层执行的，事物按流程T1,T2,,,TN。那么与之对应的就是C1,C2,,,CN。也就是由N个分布式事务组织，同时也有N个回滚事务与之对应。如下图，3个服务，A,B,C，这3个服务是按顺序执行的，如果B事务执行失败了，那么就会执行B事务的回滚操作。



当事务执行的时间比较长的话，那么需要与之对应的回滚服务。

存在的问题

我们举个转账的例子吧，A账户向B账户进行转账，A、B账户各100元，B账户需要+50元，A账户需要-50元，这个时候假如有两个不同的银行，那么会有两个服务。当B账户增加了50元的时候，A账户还没有-50元，也就意味着，此时已经将B账户增加增加好了，事务已经执行成功了。我们还需要执行回滚操作，将B账户增加的钱减回去。

因为金融行业，可以多出来钱，不能少钱，因为钱少了就找不回来了这种特性，所以在设计的时候需要先将账户加钱。

再一个SAGA只允许两层嵌套，因为流程已经很长了，嵌套多了在深度和性能上都不允许。

重试机制

还是如上例子，当A账户转账完了之后，往B账户转账失败了，那么需要将失败的情况记录下来。并且服务需要设计成幂等的，这个时候有个程序来检查任务，然后再进行重试，重试次数多了也不会对结果造成影响。

重试可以采用指数形式进行，且重试到一定次数的时候将进行预警，然后人工介入。

SAGA VS TCC

• TCC采用的中间的状态进行的数据存储，中间如果有数据查询的话不会影响结果。而SAGA会直接将事务进行提交，没有中间的结果。整个事务执行完了之后可能对结果造成变化。
• TCC需要编写try,confirm,cancel三个服务的逻辑，这样代码会非常多。但是因为逻辑代码可以控制且中间态也不影响结果，处理速度会比较快，高并发执行效率高，深受互联网欢迎。而SAGA对业务的侵入会较低，通过注解的方式可以
• 流程较长的时候需要采用SAGA，业务流程长，业务流程复杂，当针对旧代码不能改造成分布式事务的代码可以选择SAGA。TCC比较适合流程少，对实时结果要求比较高，高并发的场景比较适合。

实现SAGA的框架

支持SAGA的有 seata, Easytransaction。