分布式事物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。