saga分布式事务框架原理学习
文章目录
-
- 一、SAGA介绍
- 二、SAGA组成
- 三、SAGA的优缺点
- 四、Apache ServiceComb Saga
- 五、总结
一、SAGA介绍
SAGA来源于1987年普林斯顿大学的Hector Garcia-Molina和Kenneth Salem发表了一篇Paper Sagas，讲述的是如何处理long lived transaction（长活事务）。Saga是一个长活事务可被分解成可以交错运行的子事务集合。其中每个子事务都是一个保持数据库一致性的真实事务。通俗来说，这个长活事务是由多个本地事务所组成， 每个本地事务有相应的执行模块和补偿模块，当saga事务中的任意一个本地事务出错了， 可以通过调用相关事务对应的补偿方法恢复，达到事务的最终一致性。
随着微服务的出现，越来越多的人想解决分布式事务问题，Saga也逐步受到大家的关注，是比较受欢迎的业界分布式事务解决方案之一，目前开源的框架有华为Apache ServiceComb Saga 。
二、SAGA组成
每个Saga由一系列sub-transaction Ti 组成
每个Ti 都有对应的补偿动作Ci，补偿动作用于撤销Ti造成的结果
可以看到，和TCC相比，Saga没有“预留”动作，它的Ti就是直接提交到库。
Saga的执行顺序有两种：
T1, T2, T3, …, Tn
T1, T2, …, Tj, Cj,…, C2, C1，其中0 < j < n
Saga定义了两种恢复策略：
backward recovery，向后恢复，补偿所有已完成的事务，如果任一子事务失败。即上面提到的第二种执行顺序，其中j是发生错误的sub-transaction，这种做法的效果是撤销掉之前所有成功的sub-transation，使得整个Saga的执行结果撤销。
forward recovery，向前恢复，重试失败的事务，假设每个子事务最终都会成功。适用于必须要成功的场景，执行顺序是类似于这样的：T1, T2, …, Tj(失败), Tj(重试),…, Tn，其中j是发生错误的sub-transaction。该情况下不需要Ci。
显然，向前恢复没有必要提供补偿事务，如果你的业务中，子事务（最终）总会成功，或补偿事务难以定义或不可能，向前恢复更符合你的需求。
理论上补偿事务永不失败，然而，在分布式世界中，服务器可能会宕机，网络可能会失败，甚至数据中心也可能会停电。在这种情况下我们能做些什么？ 最后的手段是提供回退措施，比如人工干预。
三、SAGA的优缺点
优势：
1、丰富的理论基础，有较为成熟的开源框架，且Apache ServiceComb Saga已经进入apache项目孵化，未来也会不断的演进升级，且有比较完善的文档和用户手册
2、作为ServiceComb微服务分布式事务的解决方案，和ServiceComb天然无缝结合，方便平台在集成serviceComb微服务和分布式事务框架的时候减少工作量和阻力
3、基于BASE定理，提供基本可用的服务能力，与tcc相比：
有些业务很简单，套用TCC需要修改原来的业务逻辑，而Saga只需要添加一个补偿动作就行了。
TCC最少通信次数为2n，而Saga为n（n=sub-transaction的数量）。
有些第三方服务没有Try接口，TCC模式实现起来就比较tricky了，而Saga则很简单。
没有预留动作就意味着不必担心资源释放的问题，异常处理起来也更简单（请对比Saga的恢复策略和TCC的异常处理）
缺陷：
1、缺少预留动作，是优势也是缺点，导致补偿动作的实现比较麻烦：Ti就是commit，比如一个业务是发送邮件，在TCC模式下，先保存草稿（Try）再发送（Confirm），撤销的话直接删除草稿（Cancel）就行了。而Saga则就直接发送邮件了（Ti），如果要撤销则得再发送一份邮件说明撤销（Ci），实现起来有一些麻烦。
2、saga不保证ACID,只保持服务的基本可用和数据的最终一致性，事务隔离性差，要保证数据不被脏读需要在业务上进行相应的逻辑处理
四、Apache ServiceComb Saga
Apache ServiceComb Saga 是华为开源的微服务应用的数据最终一致性解决方案，已经进入apache项目孵化，是Apache ServiceComb微服务架构中的一员。
1、特性
高可用。支持集群模式。
高可靠。所有的事务事件都持久存储在数据库中。
高性能。事务事件是通过gRPC来上报的，且事务的请求信息是通过Kyro进行序列化和反序列化的。
低侵入。仅需2-3个注解和编写对应的补偿方法即可进行分布式事务。
部署简单。可通过Docker快速部署。
支持前向恢复（重试）及后向恢复（补偿）。
扩展简单。基于Pack架构很容实现多种协调机制。
2、架构
Saga Pack 架构是由alpha和omega组成，其中：
alpha充当协调者的角色，主要负责对事务进行管理和协调。
omega是微服务中内嵌的一个agent，负责对网络请求进行拦截并
向alpha上报事务事件。
下图展示了alpha, omega以及微服务三者的关系：
3、Saga 具体处理流程
Saga处理场景是要求相关的子事务提供事务处理函数同时也提供补偿函数。Saga协调器alpha会根据事务的执行情况向omega发送相关的指令，确定是否向前重试或者向后恢复。
成功场景
成功场景下，每个事务都会有开始和有对应的结束事件。
异常场景
异常场景下，omega会向alpha上报中断事件，然后alpha会向该全局事务的其它已完成的子事务发送补偿指令，确保最终所有的子事务要么都成功，要么都回滚。
超时场景 (需要调整）
超时场景下，已超时的事件会被alpha的定期扫描器检测出来，与此同时，该超时事务对应的全局事务也会被中断。
五、总结
1、作为分布式事务解决方案之一，Apache ServiceComb Saga支持tcc和saga两种模式，可实现业务逻辑的平滑迁移；
2、Apache ServiceComb Saga 基于spring注解和aop切面，对用户透明，业务侵入小，开发简单，部署容易；
3、在高可用方面。协调者alpha支持集群模式和本地持久化，不会 出现单点故障；