【微服务】（十六）—— 分布式事务Seata

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标：

Consiste ncy（一致性）

Av ailabi li ty（可用性）

Partition tolerance （分区容错性）

Eric Brewer 说，分布式系统无法同时满足这三个指标。这个结论就叫做 CAP 定理。

CAP定理– Consiste ncy

Consiste ncy（一致性）：用户访问分布式系统中的任意节点，得到的数据必须一致

CAP定理– Av ailability

Av ailability （可用性）：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

CAP定理-Partition tolerance

Partition（分区）：因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

Tolerance（容错）：在集群出现分区时，整个系统也要持续对外提供服务

2）BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：

Basically Av ailable （基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。

Soft State（软状态）：在一定时间内，允许出现中间状态，比如临时的不一致状态。

Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态

二、分布式事务Seata

1）初识seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。

致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

官网地址：http://seata.io/，其中的文档、播客中提供了大量的使用说明、源码分析。

2）Seata架构

Seata事务管理中有三个重要的角色：

TC (Transaction Coord inator) – 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

TM (Transaction Mana ger) – 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

RM (Resource Mana ger) – 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata提供了四种不同的分布式事务解决方案：

XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入

TCC模式：最终一致的分阶段事务模式，有业务侵入

AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式

SAGA模式：长事务模式，有业务侵入

3）微服务 集成seata

1、首先，引入seata相关 依赖：

<dependency&gt;    
<groupId&gt;com.alibaba.cloud</groupId>    
<artifactId>spring-cloud-starter-alibaba-seata</artifactId>    
<exclusions>        
<!--版本较低，1.3.0，因此排除-->         
<exclusion>            
<artifactId>seata-spring-boot-starter</artifactId>          
<groupId>io.seata</groupId>        
</exclusion>    
</exclusions>
</dependency>
<!--seata starter 采用1.4.2版本-->
<dependency>    
<groupId>io.seata</groupId>    
<artifactId>seata-spring-boot-starter</artifactId>    
<version>${seata.version}</version>
</dependency>

2、然后，配置 application.yml，让微服务 通过 注册 中心找到seata-tc–server：

三、XA模式

1）XA模式原理

XA 规范是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Proce ss ing）标准，

XA 规范描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范提供了支持。

2）seata的XA模式

seata的XA模式做了一些调整，但大体相似：

RM一阶段的工作：

注册分支事务到TC

执行分支业务 sql但不提交

报告执行状态到TC

TC二阶段的工作：

TC检测各分支事务执行状态

如果都成功，通知所有RM提交事务

如果有失败，通知所有RM回滚事务

RM二阶段的工作：

接收TC指令，提交或回滚事务

3）实现XA模式

Seata的starter已经完成了XA模式的自动装配，实现非常简单，步骤如下：

1、修改 application.yml文件（每个参与事务的微服务），开启XA模式：
seata:  
  data-source-proxy-mode: XA # 开启数据源代理的XA模式
2、给发起全局事务的入口方法添加@Glo balTransactional注解，

本例中是OrderServi ceImpl中的create 方法：
@Override@GlobalTransactional
public Long create(Order order) {    
    // 创建订单    
    orderMapper.insert(order);    
    // 扣余额 ...略 
    // 扣减库存 ...略    
    return order.getId();
}
3、重启服务并测试

四、AT模式

1）AT模式原理

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

阶段一RM的工作：

注册分支事务

记录 undo–log（数据快照）

执行业务 sql并提交

报告事务状态

阶段二提交时RM的工作：

删除 undo–log即可

阶段二回滚时RM的工作：

根据undo–log 恢复数据到更新前

流程如下：

五、TCC模式

1）TCC模式原理

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

Try：资源的检测和预留；

Confirm：完成资源操作业务；要求 Try 成功 Confirm 一定要能成功。

Cancel：预留资源释放，可以理解为try的反向操作。

TCC的工作模型图：

2）TCC的空回滚和业务悬挂

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行 try 操作时先执行了cancel操作，这时cancel不能做回滚，就是空回滚。

对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或canc el，这就是业务悬挂。应当阻止执行空回滚后的try 操作，避免悬挂

六、Saga模式

Saga模式是SEATA提供的长事务解决方案。也分为两个阶段：

一阶段：直接提交本地事务

二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚

Saga模式优点：

事务参与者可以基于事件驱动实现异步调用，吞吐高

一阶段直接提交事务，无锁，性能好

不用编写TCC中的三个阶段，实现简单

缺点：

软状态持续时间不确定，时效性差

没有锁，没有事务隔离，会有脏写

四种模式对比

	XA	AT	TCC	SAGA
一致性	强一致	弱一致	弱一致	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性、隔离性有高要求的业务	基于关系型数据库的大多数分布式事务场景都可以	对性能要求较高的事务。有非关系型数据库要参与的事务。	业务流程长、业务流程多参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

原文地址:https://blog.csdn.net/a6470831/article/details/124677896

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_17931.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

事务ACID原则

一、理论基础

1）CAP理论

CAP定理– Consiste ncy

CAP定理– Av ailability

CAP定理-Partition tolerance

2）BASE理论

二、分布式事务Seata

1）初识seata

2）Seata架构

3）微服务 集成seata

1、首先，引入seata相关 依赖：

2、然后，配置 application.yml，让微服务 通过 注册 中心找到seata-tc–server：

三、XA模式

1）XA模式原理

2）seata的XA模式

3）实现XA模式

1、修改 application.yml文件（每个参与事务的微服务），开启XA模式：

2、给发起全局事务的入口方法 添加@Glo balTransactional注解，

3、重启服务并测试

四、AT模式

1）AT模式原理

五、TCC模式

1）TCC模式原理

2）TCC的空回滚和业务悬挂

六、Saga模式

四种模式对比

发表回复取消回复

事务ACID原则

一、理论基础

1）CAP理论

CAP定理– Consistency

CAP定理– Availability

CAP定理-Partition tolerance

2）BASE理论

二、分布式事务Seata

1）初识seata

2）Seata架构

3）微服务集成seata

1、首先，引入seata相关依赖：

2、然后，配置application.yml，让微服务通过注册中心找到seata-tc–server：

三、XA模式

1）XA模式原理

2）seata的XA模式

3）实现XA模式

1、修改application.yml文件（每个参与事务的微服务），开启XA模式：

2、给发起全局事务的入口方法添加@GlobalTransactional注解，

3、重启服务并测试

四、AT模式

1）AT模式原理

五、TCC模式

1）TCC模式原理

2）TCC的空回滚和业务悬挂

六、Saga模式

四种模式对比

相关文章

发表回复 取消回复

CAP定理– Consiste ncy

CAP定理– Av ailability

2、然后，配置 application.yml，让微服务通过注册中心找到seata-tc–server：

1、修改 application.yml文件（每个参与事务的微服务），开启XA模式：

2、给发起全局事务的入口方法添加@Glo balTransactional注解，

发表回复取消回复