分布式事务详细介绍和LCN事务框架seata事务框架介绍

1.什么是分布式事务:    

      1.一阶段失败:  这种最好处理,直接不调用二阶段代码

      2.一阶段成功,二阶段正常执行代码失败,返回错误码:  这种情况只需要一阶段根据错误码抛出异常回滚就好了

      3.一阶段成功,但是调用二阶段接口的时候,因为网络原因,早成了下面几种情况:

          ①请求未到达二阶段接口中,此时一阶段正常根据异常回滚就可以了

          ②请求已经到达二阶段中.发起方超时自己发生了异常,这里又有两种情况:

              二阶段已经检验完毕,执行完代码,提交了事务:  这里就会造成数据不一致的情况 (seata回滚的逻辑再参与方,而不再发起方,所以也已经解决了)

              二阶段还未进行(如果自己实现的代码校验事务,这种情况很难处理,事务框架已经进行了处理,seata会首先获取全局锁,再一阶段回滚的情况下,二阶段获取不到全局锁)

1.分布式事务 二阶段提交:

    1. 事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现

    2.阶段一为准备阶段，即所有的参与者准备执行事务并锁住需要的资源。参与者执行代码准备提交数据的时候，

        向事务管理器报告代码执行结果。

    3.阶段二为提交阶段。事务管理器根据参与者报告的执行结果,来进行提交或者回滚消息.

   总结:  

    ① 事务执行阶段会一直占用着数据库资源不释放

    ②没有进行预校验

    ③事务管理器挂掉之后,会一直锁住数据库资源,不会释放

2.分布式事务 三阶段提交

    比二阶段事务,多了一个代码执行前预校验,和事务管理器挂掉之后,有超时时间,到了之后都会提交事务

   总结:   事务执行阶段会一直占用着数据库资源不释放

3.事务框架介绍

    一: LCN三阶段事务框架执行流程图:

    

 

   二: 阿里的seata

        1. 事务协调器:维护全局事务的运行状态,负责协调并驱动全局事务的提交或者回滚

        2 . 事务管理器: 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或者回滚的决议

        3. 资源管理器:控制分支事务,负责分支注册,状态汇报,并接收事务协调器的指令,驱动本地事务提交或者回滚 

        可以通过注册中心部署集群模式,实现高可用的切换,同时事务分组的模式,也可以快速切换到另外一个事务集群.

        执行流程:

            一阶段.首先获取全局锁,执行事务代码成功后,直接把业务数据和回滚日志提交到数据库,释放数据库连接资源

           二阶段: 首先获取全局锁,获取到之后,执行事务代码成功,快速提交到异步队列中,批量提交到数据库中,执行代码失败,根据回滚日志,回滚一阶段提交的数据.

        总结:

           优点:  从seata执行流程来看,他的性能优化,主要体现在一阶段释放数据库资源,二阶段提交快速化

 三.用阿里云MQ来解决

     出现原因:

       因为服务之间互相调用大多数都是http协议,而当调用另外一个服务接口的时候因为出现网络波动,造成发生异常回滚,

      可能另外一个服务已经收到消息,开始处理事物了,这就会造成脏数据

     解决:

        而阿里云MQ是用的TCP协议,所以首先他性能非常好,而且他本身发送MQ的时候会确认连接信息,然后在发送,在一定程度上

        解决了幂等问题,当另外一个服务接收到消息后,处理完成后,又会确认收到消息, 当处理完成事务后,发送消息给第一个服务,

        如果第一个服务长时间接收不到消息,就采用定时任务轮询查询事务结果

   以上使用的是普通消息,但是还是没有根本解决问题,只是弱事务

   事务消息:

   

   

 事务消息发送步骤如下：

1. 发送方将半事务消息发送至消息队列 RocketMQ 服务端。

2. RocketMQ 服务端将消息持久化成功之后，向发送方返回 Ack 确认消息已经发送成功，此时消息为半事务消息。

3. 发送方开始执行本地事务逻辑。

4. 发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback），服务端收到 Commit 状态则将半事务消息标记为可投递，订阅方最终将收到该消息；服务端收到 Rollback 状态则删除半事务消息，订阅方将不会接受该消息。

  消费方:

   处理完成本地事务后,确认收到消息,如果确认时候发送网络波动,请重新确认消息,同时做好重复消息的判断

  事务消息回查步骤如下：

1. 在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。

2. 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。

3. 发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行操作。

总结:

   优点:  性能比seata好一些,因为他无论哪个阶段都没有长期占用数据库资源

   缺点: 可能修改库存或者用户余额的地方不止一个入口,seata可以暂时锁住其他入口,MQ方式没有办法做到

             一阶段如果提交成功,因为二阶段接口响应超时,发生回滚,但是二阶段请求已经接收到,并且提交成功了,就会造成脏数据.

  问题:

       1. 发送的时候因为网络波动造成异常,本地事务回滚:   

               会主动告诉已接收成功,并且不会发送给消费方

       2. 发送成功但是MQ没有接收到消息,会主动提供接口去访问是否发送成功消息,从而选择重新发送还是回滚

       3.消费方收到消息,会告诉MQ是否消费成功MQ

 

分布式事务的问题专业名词解释

    ① 空回滚 :  意思就是 在方法中还没有提交到数据库,发生了异常,这个时候事务方法需要回滚,这个时候就是空回滚因为数据库里面没有这条记录,

    ②幂等: 是发起方服务执行完业务代码后,在调用参与方服务的时候,结果发生了网络故障,然后参与方其实收到请求了,但是事物管理器认为网络故障,没收到请求,会再次尝试请求,重复调用参与方

                  简单来讲,就是会发生多次重复调用.

   ③悬挂: 发起方在调用参与方的时候,结果因为网络原因调用超时,就会通知 TC 回滚该分布式事务，可能回滚完成后，RPC 请求才到达参与者，真正执行，从而造成悬挂