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

清疚 2022-04-24 01:02 370阅读 0赞

### 1.什么是分布式事务:     ###

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

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

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

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

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

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

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

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

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

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

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

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

**总结:**

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

②没有进行预校验

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

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

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

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

### 3.事务框架介绍 ###

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70][]

###    二: 阿里的seata ###

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

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

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

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

**执行流程:**

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

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

**总结:**

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

###  三.用阿里云MQ来解决 ###

**出现原因**:

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

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

**解决:**

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

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

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

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

**   事务消息:**

**   ** ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 1][]

事务消息发送步骤如下：

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 请求才到达参与者，真正执行，从而造成悬挂

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70]: /images/20220221/c0dec63213a9499da360c98898d2d281.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3hjMTIzX2phdmE_size_16_color_FFFFFF_t_70 1]: /images/20220221/0ddc92d418184a0cb260fa5dc00d3d9e.png