一、分布式事物问题
事物四大特性：
事物的隔离级别：读未提交、读已提交、不可重复读、串行化
- 原子性：全部成功，全部失败
- 一致性：数据内部的完成性约束
- 隔离性：数据进行写操作的时候，其他线程不能对这个线程进行写操作
- 持久性：所有的数据存储在磁盘当中
1、本地事物
微服务当中的每一个模块，事物范围都是本地范围，不会影响到其他模块的事物。
传统架构当中，横跨了多个数据库或者服务，需要保证事物的一致性，需要使用分布式事物。
二、分布式事物理论基础
2.1、CAP定理
1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。
- Consistency（一致性）：访问分布式系统下的任意节点，得到的数据都必须是一致的
- Availability（可用性）：高可用的状态。都能够得到响应
- Partition tolerance （分区容错性）：集群因为网络或者其他原因被迫成为了单节点，需要形成独立分区。
2.2、矛盾
-
在分布式系统中，系统间的网络不能100%保证健康，一定会有故障的时候，而服务有必须对外保证服务。因此Partition Tolerance不可避免。
- cp：保证高一致性，可用性降低。例如某个节点宕机，直接剔除，直到数据一致的时候重新上线
- ap：保证高可用性，例如某个服务宕机，可以使用rabbitmq预存消息，排队消费处理。
-
思考：elasticsearch集群是CP还是AP？
-
•ES集群出现分区时，故障节点会被剔除集群，数据分片会重新分配到其它节点，保证数据一致。因此是低可用性，高一致性，属于CP
2.3.BASE理论
- BASE理论是对CAP的一种解决思路，包含三个思想：
- Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
- **Soft State（软状态）：**在一定时间内，允许出现中间状态，比如临时的不一致状态。
- Eventually Consistent（最终一致性）：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。
2.4、解决分布式事物的思路
- 分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论，有两种解决思路：
AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。
- 但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：Transaction Coordinator
这里的子系统事务，称为分支事务；有关联的各个分支事务在一起称为全局事务。
三、初识Seata
3.1.Seata的架构
Seata事务管理中有三个重要的角色：
- **TC (Transaction Coordinator) -事务协调者：**维护全局和分支事``务的状态，协调全局事务提交或回滚。
- **TM (Transaction Manager) -事务管理器：**定义全局事务的范围、开始全局事务、提交或回滚全局事务。
- **RM (Resource Manager) -资源管理器：**管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata基于上述架构提供了四种不同的分布式事务解决方案：
- XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
- TCC模式：最终一致的分阶段事务模式，有业务侵入
- AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
- SAGA模式：长事务模式，有业务侵入
无论哪种方案，都离不开TC，也就是事务的协调者。
3.2、微服务集成TC (Transaction Coordinator) -事务协调者
- 引入spring-cloud-starter-alibaba-seata依赖，自定义版本，覆盖自带的版本
<!--seata-->
<dependency>
<groupId>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>
<dependency>
<groupId>io.seata</groupId>
<artifactId>seata-spring-boot-starter</artifactId>
<!--seata starter 采用1.4.2版本-->
<version>${seata.version}</version>
</dependency>
- 配置tc的yaml文件编辑
seata:
registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
type: nacos # 注册中心类型 nacos
nacos:
server-addr: 127.0.0.1:8848 # nacos地址
namespace: "" # namespace，默认为空
group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
application: seata-tc-server # seata服务名称
username: nacos
password: nacos
tx-service-group: seata-demo # 事务组名称
service:
vgroup-mapping: # 事务组与cluster的映射关系
seata-demo: SH
3、docker方式启动seata服务
四、seata的四种落地方案
4.1、XA模式
1、XA模式概述
1、XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。
XA模式执行当中，资源不会进行释放，一致性比较强。
2、RM跟TC之间的两个阶段
-
RM一阶段的工作：
① 注册分支事务到TC
② 执行分支业务sql但不提交
③ 报告执行状态到TC -
TC二阶段的工作：
TC检测各分支事务执行状态
- a.如果都成功，通知所有RM提交事务
- b.如果有失败，通知所有RM回滚事务
3、使用XA
- 配置文件配置XA模式
- 使用@GloableTransactional注解
- 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差，所以这种方式并不常用
4.2、AT模式
1、概述
AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
解决方式
- 在一阶段的时候进行提交，不用进行等待。如果需要回滚数据，通过undo表回滚备份的数据。
- 如果不用进行回滚，那么undolog表当中的数据将会删除掉。
2、使用AT模式
seata默认的模式，取消掉XA模式的配置就是AT模式了。
注解使用@gloableactional，这个注解相当于一个AOP增强。
undo_log表当中会存储前镜像数据跟后镜像数据。
通过后置镜像回滚的时候，会比对前置镜像的内容，发现不一致，则不断进行重试。最终回滚失败，除非手动将数据改回前置镜像的内容。
3、XA模式跟AT模式的区别
简述AT模式与XA模式最大的区别是什么？
- XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
- XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
- XA模式强一致；AT模式最终一致
4、AT模式产生的问题
- 如果两个全局事物操作同一个账户服务
- a全局修改1000为800，b全局事物去读那就是800，那么a回滚了，就会出现脏读问题。
- 解决方案：Seata的代理语句select for update方式解决。
- 通过设置，事物隔离界别提升到了读已提交，性能就会下降。
4.3、TCC模式
- Try：资源检查和预留
- Confirm：业务执行和提交
- Cancel：预留资源的释放
4…4、Saga模式
Saga也分为两个阶段：
- 一阶段：直接提交本地事务
- 二阶段：成功则什么都不做；失败则通过编写补偿业务来回滚
其他企业可能也会选用其他的分布式事物的解决方案，例如rabbitmq，使用消息队列的模式
学习过程中遇到的问题
1、依赖没法找到的问题
这个演示项目是gitee码云上边pull下来的
发现老师布置的资料当中并没有springboot-starter应的场景依赖，发现是aliyun的maven仓库当中不存在
其中：id是唯一标识一个mirror，name节点名，url是官方的库地址，mirrorOf代表了一个镜像的替代位置，例如central就表示代替官方的中央库。由于我阿里云的mirrorOf配置的是*号，所以导致我只能使用一个maven的远程仓库
2、nacos当中配置文件groupid问题
通过排查，是一个小问题，groupid跟配置不一致，导致出现无法获取配置信息
764
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
