526互联

分布式事务-Seata解决方案

发布时间 2023-12-07 09:52:22作者: 木乃伊人

一、定义

      Seata解决方案是分布式事务解决方案之一。常用的分布式事务解决方案有：2PC,3PC,TCC,SAGA(seata)、本地消息表、MQ消息事务、最大努力通知。

      Seata是一款分布式解决方案，致力于提供高性能和简单易用的分布式事务服务。提供事务模式有：AT,TCC,SAGA,XA。其中AT是阿里首推的模式，阿里云有商用版本GTS（Global Transaction Service 全局事务服务）。

二、3大角色

       【TC】Transaction Coordinator -事务协调者

         维护全局和分支事务的状态，驱动全局事务提交或回滚。

        【TM】Transaction Manager -事务管理者

         定义全局事务的范围：开始全局事务、提交或回滚全局事务。

        【RM】Resource Manager -资源管理者

          管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

三、SAGA模式

        分布式事务领域最有名气的解决方案之一。saga是由一系列的本地事务构成，每一个本地事务在更新完数据库之后，会发布一条消息或者一个事件来触发saga中下一个本地事务的执行，如果一个本地事务因为某些业务规则无法满足而失败，saga会执行在这个失败的事务之前成功提交的所有事务的补偿操作。

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

        【命令协调】Order Orchestrator：这种方式的工作形式就像一只乐队，由一个只会家（协调中心）来协调大家工作，协调中心来告诉saga的参与方，应该执行哪一个本地事务。

        【事务编排】Event Choreographyo：这种方式没有协调中心，整个模式的工作方式就像舞蹈一样，各个舞蹈演员按照预先安排的动作和走位各自表演，最终形成一只舞蹈。处于当前saga下的各个服务，会产生某类事件，或者监听其它服务产生的事件并决定是否需要针对监听到的时间做出响应。

         3.1、命令协调

         中央协调器（Orchestrator,简称 OSO）以命令/回复的方式与每项服务进行通信，全权负责告知每个参与者该作什么以及什么时候做。

  1.  主业务接口发起事务业务，开启订单事务。
  2. saga协调器库存服务请求扣减库存，库存服务操作后，回复处理结果。
  3. saga协调器账户服务请求扣减余额，账户服务操作后，回复处理结果，处理结果。
  4. saga协调器订单服务请求创建订单，订单服务操作后，回复。
  5. 主业务逻辑接收并处理saga协调器事务处理结果回复。

     中央协调器OSO必须事先知道执行整个事务所需的流程，如果有任何失败，它还负责通过向每个参与者发送命令来撤销之前的操作来协调分布式的回滚，基于中央协调器协调一切时，回滚要容易很多，因为协调器默认是执行正向流程，回滚时只要执行逆向流程即可。

    即执行顺序：A -> B ->C   回滚顺序： C ->B->A

         3.2、事件编排

         在基于事件的方式中，第一个服务执行完本地事务之后，会产生一个事件，其它服务会监听这个事件，触发该服务本地事务的执行，并产生新的事件。当最后一个服务执行本地事务并且不发布任何事件时，意味着分布式事务执行结束，或者它发布的时间没有被任何saga参与者听到都意味着事务结束。

  1.  主业务接口发布下单事件。
  2. 库存服务监听下单事件，扣减库存，并发布库存已扣减事件。
  3. 账户服务监听已扣减库存事件，扣减余额，并发布已扣减余额事件。
  4. 订单服务监听已扣减余额事件，创建订单，并发布下单成功事件。
  5. 主业务逻辑监听下单成功事件后，执行后续处理。

四、异常恢复

         saga模式下，每个事务参与者提供一对接口，一个做正常事务操作，一个做异常事务回滚操作。比如：支付与退款，扣款与回补等。

          

          saga支持事务恢复策略。分为两种方式：向后恢复（backward recovery），向前恢复（forward recovery）

         4.1、向后恢复

                 当执行事务失败时，补偿所有已完成的事务，是“一退到底”的方式，这种做法的效果是撤销掉之前所有成功的子事务，使得整个saga的执行结果撤销。

         

             从上图可知事务执行到了支付事务T3，但是失败了，因此事务回滚需要从C3,C2,C1依次进行回滚补偿，对应的执行顺序为：T1,T2,T3,C3,C2,C1

       4.2、向前恢复

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

    

 五、优缺点

        5.1、命令协调设计

                优点：

    1. 服务之间关系简单，避免服务间循环依赖，因为saga协调器会调用saga参与者，但参与者不会调用协调器。
    2. 程序开发简单。只需要执行命令/回复（其实回复消息也是一种事件消息），降低参与者的复杂性。
    3. 易维护扩展，在添加新步骤时，事务复杂性保持线性，回滚更容易管理，更容易实施和测试。

                缺点：

    1. 中央协调器处理逻辑容易变得庞大复杂，导致难以维护；
    2. 存在协调器单点故障风险；

        5.2、事件编排设计

                优点：

    1. 避免中央协调器单点故障风险。
    2. 当涉及的步骤较少，服务开发简单，容易实现。

                缺点：

    1. 服务之间存在循环依赖的风险。
    2. 当涉及的步骤较多，服务间的关系混乱，难以追踪调测。

六、命令VS事件 

       命令协调和事件编排如何选择：

  1. 系统复杂性：如果系统的业务逻辑复杂，事务需要严格控制和编排，命令协调方式可以提供更好的可见性和可控性。
  2. 系统扩展性：如果系统需要频繁扩展和修改，需要一定的灵活性，事件编排方式可以提供解耦和扩展性更好的架构。
  3. 性能需求：如果需要更好的性能和可伸缩性，并行执行事务的各个步骤，事件编排方式更适合。
  4. 异步需求：如果系统需要异步处理和解耦，事件编排方式提供了更好的可行性。