Seata模式

news2024/11/19 23:41:40

爬虫组件分析

目录
- 概述
- - 需求：
- 设计思路
- 实现思路分析
- - 1.一、AT 模式
参考资料和推荐阅读

Survive by day and develop by night.
talk for import biz , show your perfect code,full busy，skip hardness,make a better result,wait for change,challenge Survive.
happy for hardess to solve denpendies.

1、对于seata 来说默认开启的就是 AT模式，而且如果你依赖 seata-spring-boot-starter 时，自动代理数据源，无需额外处理
2、对于AT模式在回滚的时候会找到 undo_log 中的前镜像与后镜像，来进行恢复。
但是在恢复的时候，会比较后镜像是否有没有被修改过，即进行数据进行比较，如果有不同，说明数据被当前全局事务之外的动作进行了修改，这个时候AT模式做数据校验的时候，会回滚失败，因为校验不通过，我们也可以通过配置参数关闭这个前后镜像的校验过程，不过这个是非常不建议的，因为，被其他线程修改了导致不能还原现场这种情况，确实还是需要人为去处理的

1、我们使用注解 @GlobalTransactional开启seata的AT模式的事务管理，而且因为是使用的是seata-starter，那这个注解会自动代理AT模式的数据源，具体代码如下，可以看到代码主要分为两部分，第一部分是调用自己order服务的2个表的mapper 插入数据到gxm-300，第二部分是远程调用device的两个mapper来进行插入数据到gxm-301

3、再测试不成功，即传参的时候id不为空，则seata数据全局事务就会生效，2个数据库4张表都没有数据库，说明seata的AT模式生效了，

在端点处停止的时候，我们观察gxm-300数据库和gxm-301数据库，你会发现，4个mapper的插入数据都已经插入到数据库了，并且一个mapper会在对应的undo_log表中插入一条数据，其中会有前置镜像数据和后置镜像数据，以及分支id branch_id

4、 gxm-301 的 undo_log表

5、seata 的 branch_table表
全局表的只有一条数据，因为4个mapper是在一个全局事务里面的，只是分了4个分支。

关联关系就是关联关系就是branch_id和 transaction_id，一个 transaction_id 表示一次全局事务的开始

旗下会有多个branch_id分支事务
那么这些表都不会有数据，因为我们的全局事务结束了，保证的当次业务的流程🆗了，即使是失败了，但是帮你回滚了。

1.1.3、AT模式回滚失败，处理1、对于前面的1.1.2节的调试，我这里出现了问题，可能是因为我断点停留时间太长了，会发现相关表有数据，说seata的at模式回滚失败了。接下来我们就要去处理了。
于是我们到对应的数据中找到它的undo_log，可以看到对应的分支id也是和前面的对应的上的，其中rollback_info字段记录的就是前置镜像的数据和后置镜像的数据。
根据上述的json文件内容，直接操作是insert，而device没有插入成功，但是它插入成功了，我们把相关的数据删除即可，后续如果是其他情况，比如update这种，根据前后镜像数据，按照需求处理。

测试seata回滚时，镜像数据被其他事务修改后，无法回滚成功的情况

1、首先大家要了解seata的AT模式流程，官方文档：Seata AT 模式
这种情况，分两种处理方式
而且rm此时会一直尝试，可以看后面的那张图，一直尝试一直失败，控制台一直打印尝试失败的信息。
然后记得seata数据库的相关表的数据也得删除偶，以及对应的undo_log表数据也需要删除。

1、在本地修改的事务上加上@GlobalLock
其中参数 lockRetryTimes 尝试间隔时间，lockRetryTimes尝试次数，说明在多少秒内间隔多少次会不断重试获取全局锁，如果该记录在全局事务中，则会失败.
而TCC则需要我们提供相应的接口，官方也都表明了 Seata TCC 模式，
@LocalTCC

TwoPhaseBusinessAction

@BusinessActionContextParameter 注解可以将参数传递到二阶段（commitMethod/rollbackMethod）的方法，这个也是下面提到的问题，第二阶段获取的参数只能是第一阶段的一开始通过注解定义的参数值，即使你在第一阶段修改，添加，也没法在第二阶段获取到最新的参数值。

3、TCC 参与者需要实现三个方法，分别是一阶段 Try 方法、二阶段 Confirm 方法以及二阶段 Cancel 方法。在 TCC 参与者的接口中需要先加上 @TwoPhaseBusinessAction 注解，并声明这个三个方法，如下所示

@TwoPhaseBusinessAction 注解属性说明：

name ：TCC参与者的名称，可自定义，但必须全局唯一。

commitMethod：指定二阶段 Confirm 方法的名称，可自定义。

rollbackMethod：指定二阶段 Cancel 方法的名称，可自定义。

Try：第一个参数类型必须是BusinessActionContext，后续参数的个数和类型可以自定义。

Confirm：有且仅有一个参数，参数类型必须是 BusinessActionContext，后续为相应的参数名（businessActionContext）。

Cancel：有且仅有一个参数，参数类型必须是 BusinessActionContext，后续为相应的参数名（businessActionContext）。

2.2、如何控制异常
在 TCC 模型执行的过程中，还可能会出现各种异常，其中最为常见的有空回滚、幂等、悬挂等。
空回滚指的是在一个分布式事务中，在没有调用参与方的 Try 方法的情况下，TM 驱动二阶段回滚调用了参与方的 Cancel 方法。
在全局事务开启后，参与者 A 分支注册完成之后会执行参与者一阶段 RPC 方法，如果此时参与者 A 所在的机器发生宕机，网络异常，都会造成 RPC 调用失败，即参与者 A 一阶段方法未成功执行，但是此时全局事务已经开启，Seata 必须要推进到终态，在全局事务回滚时会调用参与者 A 的 Cancel 方法，从而造成空回滚.

在全局事务开启后，参与者 A 分支注册完成之后会执行参与者一阶段 RPC 方法，如果此时参与者 A 所在的机器发生宕机，网络异常，都会造成 RPC 调用失败，即参与者 A 一阶段方法未成功执行，但是此时全局事务已经开启，Seata 必须要推进到终态，在全局事务回滚时会调用参与者 A 的 Cancel 方法，从而造成空回滚

在参与者 A 执行完二阶段之后，由于网络抖动或者宕机问题，会造成 TC 收不到参与者 A 执行二阶段的返回结果，TC 会重复发起调用，直到二阶段执行结果成功。
同样的也是在 TCC 事务控制表中增加一个记录状态的字段 status，该字段有 3 个值，分别为：
tried：1
committed：2
rollbacked：3

如何处理悬挂？
二阶段 Cancel 方法

在 TCC 事务控制表记录状态的字段 status 中增加一个状态：

4、代码中可以增加参数useTCCFence = true，开启seata的放悬挂

saga目前提供了基于状态机的方式，而状态机的语言官方也给出了一个可视化的界面状态机设计器演示地址:http://seata.io/saga_designer/index.html

XA模式：
3、如果项目没有性能的要求我建议使用XA模式，因为，它是强一致性，而AT模式是最总一致性。
空补偿：原服务未执行，补偿服务执行了

在这里插入图片描述