微服务学习笔记 Saga模式

单体架构下，大多数采用的事务的ACID原则来保证事务，但是在微服务架构下，由于要保证低耦合等的要求，采用ACD Saga的模式来保证事务。（虽然也可以使用分布式事务，即"两阶段提交"，但是这会导致服务和服务之间的强耦合）

所谓的Saga，就是通过使用异步消息来协调一系列本地事务，从而维护多个服务之间的数据一致性。

每个TXN是一个本地事务，当本地事务提交后，通过异步消息来告知下个服务开始执行其本地事务，以此类推。

使用Saga是不考虑ACID的I（隔离性）的。此外，和使用分布式事务不同，每完成一个本地事务的步骤，Saga是直接提交的。这也就导致了如果出现了某个服务中的事务发生了错误，就要使用补偿事务来回滚做出的改变

补偿事务

补偿事务就是做正向事务的反操作，例如create的补偿操作就是delete。当Saga中含有多个事务时，进行补偿事务回滚操作就要按照正向执行事务的反向顺序执行补偿事务。

Saga的协调模式

Saga有两种模式能够协调Saga参与方的事务

协同式Saga

所谓的协同模式就是成员每完成一个事务，将完成事务的消息发布到消息管道中，其他成员通过订阅管道中的消息来判断是否执行本地事务。比如A完成了一个a事务，就将completed消息发布到a消息管道中，B通过订阅知道了a消息管道中的completed消息，就开始执行本地b事务；同理C通过订阅知道了a消息管道中的completed消息，就开始执行本地c事务。B，C完成事务后，也将其completed消息发送到b消息管道和c消息管道。A通过订阅b消息管道和c消息管道，了解到整个Saga事务执行完毕。当然，如果中间过程出现事务失败需要回滚的情况，也是通过将失败消息发布到消息管道内，告知其他服务需要执行补偿事务来回滚事务。

PS:123456代表执行顺序

优势

• 简单
• 参与方订阅事件，彼此之间松耦合

劣势

• 会有循环依赖的风险
• 会有紧耦合的风险（参与方需要订阅所有会影响他的事件，而且可能需要和消息发送方代码保持同步更新）

编排式Saga

所谓的编排式Saga，就是在主服务内生成一个Saga编排器类（对象）。而所谓的Saga编排器就是用来协调每个Saga参与者本地事务顺序的，同时，Saga编排器可以视为一个状态机，即Saga编排器在每执行完一个事务之后，将其自身的状态变更成为初始状态，中间状态，完成状态等对应每个当前执行事务情况的状态。
Saga的工作顺序如此：通过消息管道向其他Saga参与者发送事务执行命令；参与者收到命令后执行本地事务，并在执行完毕后，通过消息管道回复给Saga编排器；Saga编排器收到回复消息后，根据顺序再向其他的参与者发送命令。以此类推。

PS:123456代表执行顺序

优势

• 不会产生循环依赖，只有编排器依赖参与者，而参与者不会依赖编排器
• 耦合少，服务只要实现编排器请求的api（事务操作）即可，服务不需要知道其他Saga参与方发布的事件
• 能够简化业务逻辑。主服务只有开始和结束两个状态，并不需要关心Saga的中间状态。业务更为简单。

劣势

• 编排器可以会存在集中太多业务的风险。但是可以通过让编排器只负责排序，不负责任何业务的方法来规避这种风险。

综上所述，编排式Saga更为推荐

参考：《微服务架构设计模式》