分布式事务·入门与解决·壹

1 基础理论

1.1 本地事务

事务四大特性（ACID）：事务的A（Atomicity）原子性、C（Consistency）一致性、I（Isolation）隔离性、D（Durability） 持久性

例如：单体项目中同时操作多张表，那么必须添加@Transactional开启事务注解。因而本地事务也称之为单机事务。

1.2.分布式事务

分布式事务：由多个服务或数据库架构产生的事务。

案例：下单付款

当把三件事看做一个事务，则相关操作需满足事务原子性“要么全部成功，要么全部失败”，此类种种称为：分布式系统下的事务

1.3 CAP定理

CAP定理中：三个指标不可能同时做到

CAP定理中：为啥三个指标不可能同时做到？

假设N1、N2通信是网络突然断开，当用户给N2发送数据，数据需要经过N1与N2之间的链路通信，此时两种解决思路：
①牺牲数据的一致性，响应旧的数据给用户；
②牺牲可用性，阻塞等待，直至网络通信恢复，再响应给用户。

参考：分布式CAP定理，为什么不能同时满足三个特性？

指标	解释
C （Consistency）一致性	用户访问分布式系统中的任意节点，得到的数据必须一致。
A（Availability） 可用性	用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝。
P（Partition tolerance ） 分区容错性	因为网络故障或其它原因导致分布式系统中的部分节点与其它节点失去连接，形成独立分区。

2.2 CAP的一种解决思想——BASE理论

思想	解释
Basically Available（基本可用）	分布式系统在出现故障时，允许损失部分可用性，即保证核心业务可用
Soft State（软状态）	在一定时间内，允许出现中间状态，比如临时的不一致状态
Eventually Consistent（最终一致性）	在软状态结束后，最终达到数据一致

2.3.分布式事务解决思路AP、CP、TC

模式	解释
CP模式	各子事务执行后互相等待，同时提交，同时回滚，达成强一致，等待过程中，处于弱可用状态。
AP模式	各子事务分别执行和提交，过程中允许出现结果不一致（软状态），最终需采用弥补措施，实现数据的最终一致性
TC（事务协调者）	CP、AP模式中子事务间互相通讯，协调事务状态的协调者

• 子系统事务又叫分支事务。
• 有关联的分支组成一体成称为全局事务。
  

2 分布式事务的一种解决方案——Seata

官网地址：http://seata.io/

2.1 Seata的架构

角色	功能
TC (Transaction Coordinator) 事务协调者	维护全局和分支的状态，协调全局事务提交或回滚
RM (Resource Manager) 资源管理器、事务参与者	管理分支事务资源，与TC通信以注册分支事务和报告分支事务状态，驱动分支事务提交或回滚
TM (Transaction Manager) 事务管理器	定义全局事务范围、开始全局事务、提交或回滚全局事务

整体的架构图：

Seata基于上述架构提供四种不同分布式事务解决方案，注意：TC事务协调者为无论哪种模式的必须 ：

解决方案	解释
XA模式	强一致性分阶段事务模式，牺牲一定可用性，无业务侵入
TCC模式	最终一致性分阶段事务模式，有业务侵入
TCC模式	最终一致性分阶段事务模式 无业务侵入，Seata默认模式
TCC模式	长事务模式，有业务侵入

2.2 部署TC服务

参阅： seata的部署和集成

2.3.微服务集成Seata

2.3.1.引入依赖

由于大多数SpringCloud版本自带seata驱动版本太低，我们需要排除自带依赖。

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-seataartifactId>
    <exclusions>
         
        <exclusion>
            <artifactId>seata-spring-boot-starterartifactId>
            <groupId>io.seatagroupId>
        exclusion>
    exclusions>
dependency>
<dependency>
    <groupId>io.seatagroupId>
    <artifactId>seata-spring-boot-starterartifactId>
    
    <version>${seata.version}version>
dependency>

2.3.2 配置TC地址

在每个分布式服务application.yml中，配置TC服务信息，通过注册中心nacos，结合服务名称获取TC地址：

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

2.3.3 微服务如何根据配置寻找TC地址?

注册到Nacos中的微服务，确定一个具体实例需四个信息：

• namespace为空，就是默认的public
• 综上，TC服务信息：public@DEFAULT_GROUP@seata-tc-server@SH，据此去Nacos拉取对应的实例信息。

属性	解释
namespace	命名空间
group	分组
application	服务名
cluster	集群名

2.3.4 报错jdbc：java.lang.NoSuchMethodException: com.mysql.cj.conf.PropertySet.getBooleanReadableProperty…解决方案

报错原因：seata-server-1.4.2开发时候MySQL只更新到8.0.11，因此MySQL数据库只支持版本≤ 8.0.11

解决方案：不用卸载更换MySQL版本，只需要把数据库 驱动 ≤ 8.0.11

3 Seata四种事务模式验证

3.1 XA规范

XA 规范： X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，描述了TM（全局事务范围，开始、提交或回滚全局事务）与RM（管理分支事务资源，在TC上注册事务分支、报告分支状态最终驱动分支事务提交或回滚）间接口，主流的数据库大部分都支持 XA 规范。

3.1.1 两阶段提交

实现原理两阶段提交：

正常情况：

一阶段：

• TC（事务协调者）通知每个RM（事务参与者）执行本地事务（单机/单体事务）。
• 本地事务执行完成后报告事务执行状态给TC，此时事务不提交，继续持有数据库锁（联想多线程操作同一资源）。

异常情况：

二阶段：

• TC基于一阶段的报告判断下一步操作
• ①若一阶段都成功，通知所有RM（事务参与者）提交事务（数据库CRUD）。
• ②若一阶段任意一个TC失败，通知所有RM回滚事务。

3.1.2 Seata的XA模型实现

Seata对原始XA模式进行简单的封装和改造：

RM（事务参与者）一阶段的工作：
①注册分支事务到TC
②执行分支业务sql但不提交
③报告执行状态到TC

TC二阶段工作：
TC检测各分支事务执行状态
①若都成功，通知所有RM提交事务
②若有失败，通知所有RM回滚事务

RM二阶段工作：
接收TC指令，提交或回滚事务

3.3.3 优缺点

XA模式的优点：

• 事务的强一致性，满足ACID原则。
• 常用数据库都支持，实现简单，无代码侵入

XA模式的缺点:

• 一阶段需锁定数据库资源，等待二阶段结束才释放，性能较差
• 依赖关系型数据库实现事务

3.3.4 实现XA模式

3.3.4.1 每个微服务application.yml中开启XA模式

seata:
  data-source-proxy-mode: XA

3.3.4.2 全局事务入口方法添加@GlobalTransactional注解

3.3.4.3 postman测试