> 文档中心 > 分布式事务之Seata项目集成部署

分布式事务之Seata项目集成部署


分布式事务之Seata

分布式服务案例

  1. 原子性:事务中的所有操作,要么全部成功,要么全部失败
  2. 一致性:要保证数据库内部完整性约束、声明性约束
  3. 隔离性:对同一资源操作的事务不能同时发生
  4. 持久性:对数据库做的一切修改将永久保存,不管是否出现故障

分布式服务案例

微服务下单业务,在下单时会调用订单服务,创建订单并写入数据库。然后订单服务调用账户服务和库存服务:

  1. 账户服务负责扣减用户余额
  2. 库存服务负责扣减商品库存

分布式事务之Seata项目集成部署

微服务项目引入

项目地址:联系我

  1. 创建数据库,名为seata-demo,然后导入课前资料提供的SQL文件:

  2. 项目结构如下(基于figen的远程调用):

    分布式事务之Seata项目集成部署

  3. 通过postman软件进行接口测试

用户id与订单编号都是与数据库中初始的一致

分布式事务之Seata项目集成部署

  1. 启动项目测试结果:

在分布式系统下,一个业务跨越多个服务或数据源,每个服务都是一个分支事务,要保证所有分支事务最终状态一致,这样的事务就是分布式事务。

1. 如果填写的用户id和商品编号的话,都会对数据库进行一个更改2. 如果填写的用户id和编号id都不对获取超出了订单的库存,那么添加的订单数据会成功以及扣款都会成功,二对于库存的修改就会失败,这就不服务微服务事务的保护了,要么一起成功要么一起失败,如果需要通过事务回滚就需要学习本次的Seata进行分布式的事务管理

分布式事务之Seata项目集成部署

1、理论基础

1.1、CAP定理

分布系统有三个指标:
  1. Consistency(一致性)
  2. Availability(可用性)
  3. Partition tolerance (分区容错性)

分布式事务之Seata项目集成部署

1998年,加州大学的计算机科学家 Eric Brewer 说,分布式系统无法同时满足这三个指标。

这个结论就叫做 CAP 定理。

1.1.1、CAP定理- Consistency

Consistency(一致性):用户访问分布式系统中的任意节点,得到的数据必须一致

如果有两个节点,那么节点一与节点二的数据必须同步更新

1.1.2、CAP定理- Availability

Availability (可用性):用户访问集群中的任意健康节点,必须能得到响应,而不是超时或拒绝

1.1.3、CAP定理-Partition tolerance

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

Tolerance(容错):在集群出现分区时,整个系统也要持续对外提供服务

1.1.4、小结

  1. 分布式系统节点通过网络连接,一定会出现分区问题(P)
  2. 当分区出现时,系统的一致性(C)和可用性(A)就无法同时满足

拓展:ES集群出现分区时,故障节点会被剔除集群,数据分片会重新分配到其它节点,保证数据一致。因此是低可用性,高一致性,属于CP

1.2、BASE理论

1.2.1、BASE理论是对CAP的一种解决思路,包含三个思想:

  1. Basically Available (基本可用):分布式系统在出现故障时,允许损失部分可用性,即保证核心可用。
  2. Soft State(软状态):在一定时间内,允许出现中间状态,比如临时的不一致状态。
  3. Eventually Consistent(最终一致性):虽然无法保证强一致性,但是在软状态结束后,最终达到数据一致。

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

  1. AP模式:各子事务分别执行和提交,允许出现结果不一致,然后采用弥补措施恢复数据即可,实现最终一致。
  2. CP模式:各个子事务执行后互相等待,同时提交,同时回滚,达成强一致。但事务等待过程中,处于弱可用状态。

分布式事务模型

1.2.3、分布式事务模型

解决分布式事务,各个子系统之间必须能感知到彼此的事务状态,才能保证状态一致,因此需要一个事务协调者来协调每一个事务的参与者(子系统事务)。

这里的子系统事务,称为分支事务;有关联的各个分支事务在一起称为全局事务

分布式事务之Seata项目集成部署

1.2.4、小结

三个思想:

  1. 基本可用
  2. 软状态
  3. 最终一致

解决分布式事务的思想和模型:

  1. 全局事务:整个分布式事务
  2. 分支事务:分布式事务中包含的每个子系统的事务
  3. 最终一致思想:各分支事务分别执行并提交,如果有不一致的情况,再想办法恢复数据
  4. 强一致思想:各分支事务执行完业务不要提交,等待彼此结果。而后统一提交或回滚

3、Seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务,为用户打造一站式的分布式解决方案。官网地址:https://seata.io/zh-cn/,其中的文档、播客中提供了大量的使用说明、源码分析。

3.1、Seata的架构

Seata事务管理中有三个重要的角色:
  1. TC (Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,协调全局事务提交或回滚。
  2. TM (Transaction Manager) - 事务管理器:定义全局事务的范围、开始全局事务、提交或回滚全局事务。
  3. RM (Resource Manager) - 资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。

分布式事务之Seata项目集成部署

Seata提供了四种不同的分布式事务解决方案:
  1. XA模式:强一致性分阶段事务模式,牺牲了一定的可用性,无业务侵入
  2. TCC模式:最终一致的分阶段事务模式,有业务侵入
  3. AT模式:最终一致的分阶段事务模式,无业务侵入,也是Seata的默认模式
  4. SAGA模式:长事务模式,有业务侵入

3.2、部署TC服务

请查看博客:

4、微服务集成seata

seata版本为:1.4

注意:这里的jdk版本是1.8,如果使用高版本的可能会出现不兼容现象导致启动报错

4.1、首先,引入seata相关依赖:

<dependency>    <groupId>com.alibaba.cloud</groupId>    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>        <exclusions> <exclusion>     <artifactId>seata-spring-boot-starter</artifactId>     <groupId>io.seata</groupId> </exclusion>    </exclusions></dependency><dependency>    <groupId>io.seata</groupId>    <artifactId>seata-spring-boot-starter</artifactId>    <version>1.4.2</version></dependency>

4.2、然后,配置application.yml,让微服务通过注册中心找到seata-tc-server:

分布式事务之Seata项目集成部署

# 配置seata的注册中心seata:  registry:    type: nacos    nacos:      server-addr: 127.0.0.1:8848      namespace: ""      group: DEFAULT_GROUP      application: seata-tc-server      username: nacos      password: nacos  tx-service-group: seata-demo # 事务组名称  service:    vgroup-mapping: # 事务组与cluster的映射关系      seata-demo: SH

其他的两个服务都是一样的步骤

4.3、重启项目

查看seata的控制输出

分布式事务之Seata项目集成部署

出现这样的代码以及集成成功了

4.4、小结

nacos服务名称组成包括?

  • namespace + group + serviceName + cluster

seata客户端获取tc的cluster名称方式?

  • 以tx-group-service的值为key到vgroupMapping中查找

茶叶商城