Saga模型起源于1987年 Hector Garcia-Molina,Kenneth Salem 发表的论文《Sagas》,是分布式事务相关概念最早出现的。
Saga模型是把一个分布式事务拆分为多个本地事务,每个本地事务都有相应的执行模块和补偿模块(对应TCC中的Confirm和Cancel),当Saga事务中任意一个本地事务出错时,可以通过调用相关的补偿方法恢复之前的事务,达到事务最终一致性。
从Saga模型的上述定义中,Saga 模型可以满足事务的三个特性:
从数据隔离性上分析,我们可以发现Saga模型无法保证外部的原子性和隔离性,因为可以查看其他sagas的部分结果,论文中有对应的表述:
Saga 事务和 TCC 事务一样,都是强依靠业务改造,所以要求业务方在设计上要遵循四个策略:
虽然 Saga 和 TCC 都是补偿事务,但是由于提交阶段不同,所以两者也是有不同的:
目前业界提供了两类Saga的实现方式,一种是基于业务逻辑层Proxy设计(基于AOP实现),比如华为的ServiceComb;一种是状态机实现的机制,比如阿里的Seata的Saga模式。
Aop Proxy实现原理如下:
业务逻辑层调用上加上事务注解@Around(“execution(* *(..)) && @annotation(TX)”),Proxy在真正业务逻辑被调用之前, 生成一个全局唯一 TXID 标示事务组,TXID保存在ThreadLocal变量里,方法开始前写入,完成后清除,并向远端数据库写入 TXID 并把事务组置为开始状态。业务逻辑层调用数据访问层之前,通过RPCProxy代理记录当前调用请求参数。如果业务正常,调用完成后,当前方法的调用记录存档或删除。如果业务异常,查询调用链反向补偿
数据访问层设计:原始接口必须保证幂等性,满足本地原子性。提供补偿接口实现反向操作。这方面可以在框架层面做一些通用补偿实现,降低使用成本,当然补偿接口也是必须也有幂等性保证。还可以提供补偿注解,基于原则接口方法,在方法名加注解标注补偿方法名:@Compensable(cancelMethod=“cancelRecord”)
补偿策略:首先是调用执行失败,修改事务组状态;其次分布式事务补偿服务异步执行补偿
状态机引擎Saga原理如下:流程为--先执行stateA, 再执行stateB,然后执行stateC
"状态"的执行是基于事件驱动的模型,stateA执行完成后,会产生路由消息放入EventQueue,事件消费端从EventQueue取出消息,执行stateB。
交易创建订单事务组正常流程:锁库存->减红包->创建订单
交易创建订单事务组异常流程:
我们已经介绍了XA、2PC、3PC、TCC四种事务模型,但是都不大推荐使用。本文的Saga模式是我主推荐的事务模型,可以适用于大部分的同步事务上。因为华为的ServiceComb中的事务模块目前并非十分独立,所以强烈推荐Seata。Seata不仅支持Saga模式,,还提供了状态机的可视化操作制作,使用成本比较底下。而且Seata的AT模式利用数据库镜像实现了自动补偿机制,又更进一步的优化了Saga模型的缺点。
林淮川
毕业于西安交通大学;奈学教育《百万架构师训练营》讲师 和 企业级源码内源负责人,前大树金融高级架构师、技术委员会开创者、技术总监;前天阳宏业交易事业部技术主管;多年互联网金融行业(ToB)经验。
孙玄
毕业于浙江大学,奈学教育创始人兼CEO,前转转公司技术委员会主席,前58集团技术委员会主席,前百度资深研发工程师,腾讯云TVP,阿里云MVP,在线直播大课《百万架构师》品牌创始人。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。