Saga分布式事务

Saga是分布式事务领域最有名气的解决方案之一，最初出现在1987年Hector Garcaa-Molrna & Kenneth Salem发表的论文SAGAS里。

Saga是由一系列的本地事务构成。

每一个本地事务在更新完数据库之后，会发布一条消息或者一个事件来触发Saga中的下一个本地事务的执行。

如果一个本地事务因为某些业务规则无法满足而失败，Saga会执行在这个失败的事务之前成功提交的所有事务的补偿操作。

Saga的实现有很多种方式，其中最流行的两种方式

基于事件的方式:

这种方式没有协调中心，整个模式的工作方式就像舞蹈一样，各个舞蹈演员按照预先编排的动作和走位各自表演，最终形成一只舞蹈。

处于当前Saga下的各个服务，会产生某类事件，或者监听其它服务产生的事件并决定是否需要针对监听到的事件做出响应。

基于命令的方式:

这种方式的工作形式就像一只乐队，由一个指挥家（协调中心）来协调大家的工作。

协调中心来告诉Saga的参与方应该执行哪一个本地事务。

saga 事务有两种恢复策略

向前恢复（forward recovery）：

对于执行不通过的事务，会尝试重试事务，这里有一个假设就是每个子事务最终都会成功。这种方式适用于必须要成功的场景。

向后恢复（backward recovery）：

在执行事务失败时，补偿所有已完成的事务，是 “一退到底” 的方式。

saga 事务协调

Choreography（编排）:

参与者（子事务）之间的调用、分配、决策和排序，通过交换事件进行进行。是一种去中心化的模式，参与者之间通过消息机制进行沟通，通过监听器的方式监听其他参与者发出的消息，从而执行后续的逻辑处理。由于没有中间协调点，靠参与靠自己进行相互协调。

优点：

简单：

每个子事务进行操作时只用发布事件消息，其他子事务监听处理。

松耦合：

参与者（服务）之间通过订阅事件进行沟通，组合会更加灵活

缺点：

理解困难：

没有对业务流程进行完整的描述，要了解整个事务的执行过程需要通过阅读代码完成。

增加开发人员理解和维护代码的难度。

存在服务的循环依赖：

由于通过消息和事件进行沟通，参与者之间会存在循环依赖的情况.

也就是 A 服务调用 B 服务，B 服务又调用 A 服务的情况。

这也增加了架构设计的复杂度，在设计初期需要认真考虑。

紧耦合风险：

每个参与者执行的方法都依赖于上一步参与者发出的消息，但是上一步的参与者的所有消息都需要被订阅，才能了解参与者的真实状态，无形中增加了两个服务的耦合度。

Orchestration（控制）:

saga 提供一个控制类，其方便参与者之前的协调工作。

事务执行的命令从控制类发起，按照逻辑顺序请求 saga 的参与者，从参与者那里接受到反馈以后，控制类再发起向其他参与者的调用。

所有 saga 的参与者都围绕这个控制类进行沟通和协调工作。

优点：

避免循环依赖：

在编排模式中存在参与者之间的循环调用，而中心控制类的方式可以避免这种情况的发生。

降低复杂性：

所有事务交给控制器完成，它负责命令的执行和回复的处理，参与者只需要完成自身的任务，不用考虑处理消息的方式，降低参与者接入的复杂性。

容易测试：

测试工作集中在集中控制类上，其他服务单独测试功能即可。

容易扩展：

如果事务需要添加新步骤，只需修改控制类，保持事务复杂性保持线性，回滚更容易管理

缺点：

依赖控制器：

控制器中集中太多逻辑的风险。

增加管理难度：

这种模式除了管理各个业务服务以外，还需要额外管理控制类服务，无形中增加了管理的难度和复杂度。

而且存在单点风险，一旦控制器出现问题，整个业务就处于瘫痪中。

总结

Saga 是针对分布式长活事务的解决方案，针对事务长、多、复杂的情况，特别是服务由多个公司开发具有不可控性，可以使用 Saga 模式进行分布式事务的处理。

Saga 在处理事务一致性方面采取了向前恢复和向后恢复策略，前者通过不断重试的方式保证事务完成，而后者通过子事务的补偿事务，逐一回滚的方式让事务标记失败。

在分布式协调方面，Saga 采用了两种模式：编排和控制。

前者让参与者（服务）之间通过消息进行沟通，根据事件出发事务的执行流程，是一种去中心化的模式。

后者通过中心控制类，处理事务的执行和回滚步骤，统一调用服务和接受服务的反馈。