分布式事务学习笔记 - Seata 事务

2.1 背景
事务，最先了解的是 数据库事务。数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是ACID。
在微服务架构中，分布式事务不可避免，分布式系统的核心就是要解决在复杂的网络环境下，如何保证数据的一致性，就提出了新的理论：CAP 原理，
一致性(Consistency) 、可用性(Availability) 、分区容错性(Partition tolerance) 。
在任何分布式系统中，只能有两种选择

2.2 事务原理

2.2.1 2PC 模式( XA Transactions )
MySQL从5.5版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。
XA 是一个两阶段提交协议，该协议分为以下两个阶段:
第一阶段：事务协调器要求每个涉及到事务的数据库 预提交(precommit)此操作，并反映是否可以提交.
第二阶段：在收到参与者的 yes反馈后，事务协调器再要求每个数据库提交数据
（其中若任何一个 参与者 向 事务协调器 反馈了 No 响应,或者等待超时，所有参与的本地数据库事务都会被要求回滚）
随后 在收到事务协调器的之后释放整个事务执行期间占用的事务资源。

2PC出现单点问题的三种情况

(1)协调者正常,参与者宕机
由于 协调者 无法收集到所有 参与者 的反馈，会陷入阻塞情况。
解决方案:引入超时机制,如果协调者在超过指定的时间还没有收到参与者的反馈,事务就失败,向所有节点发送终止事务请求。
(2)协调者宕机,参与者正常
无论处于哪个阶段，由于协调者宕机，无法发送提交请求，所有处于执行了操作但是未提交状态的参与者都会陷入阻塞情况
解决方案:引入协调者备份,同时协调者需记录操作日志.当检测到协调者宕机一段时间后，协调者备份取代协调者，并读取操作日志，向所有参与者询问状态
(3)协调者和参与者都宕机
若所有参与者都没有真正执行commit，所以只需重新在剩余的参与者中重新选出一个协调者，新的协调者在重新执行第一阶段和第二阶段就可以了。
若协调器已经完成二阶段，部分参与者完成commit，就无法保证这个异常期间的一致性问题。

2PC 模式的缺点：
性能问题，资源占用过大。2PC无法解决的问题是 当在协调器发送最终 提交 命令时，有参与者提交失败，就有可能出现数据不一致的情况。
2.2.2 3PC三阶段提交
三阶段 同时在协调器和参与者中引入超时机制。
第一阶段：CanCommit 协调器询问参与者是否可以正常进行，( 参与者尝试获取本地数据库锁 )
第二阶段：PreCommit 预提交 询问参与者是否可以提交
第三阶段：DoCommit 参与者提交

除了在 2PC的一阶段基础上增加了 提前询问状态的 缓冲阶段，还增加了参与者的超时时间设置。

三阶段提交协议（3PC）主要是为了解决两阶段提交协议的阻塞问题，2pc存在的问题是当协作者崩溃时，参与者不能做出最后的选择。因此参与者可能在协作者恢复之前保持阻塞

2.2.3 TCC（补偿事务）
补偿事务 是业务层面的事务处理概念，它分为三个阶段

Try : 业务应用向服务尝试执行业务，并且锁定业务需要的资源。完成所有业务检查(一致性)。
Confirm：确认执行业务 向服务发送Commit 命令。
Cancel： 取消执行业务 ，发送Rollback 命令。

2.3 分布式事务框架
2.3.1 SpringCloud + seata

Seata的分布式事务解决方案是业务层面的解决方案，只依赖于单台数据库的事务能力。Seata框架中一个分布式事务包含3中角色： TC (Transaction Coordinator) ,TM (Transaction Manager ) ,RM (Resource Manager)
Transaction Coordinator (TC)： 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。
Transaction Manager ™： 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。
Resource Manager (RM)： 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。
整个Seata 事务流程如上图：

1. TM发起分布式事务， 向 TC 中申请一个唯一的XID 用于各个本地事务之间传输。
2. RM 本地事务向TC 申请一个事务分支，并且完成本地事务分支的提交，然后将结果汇报至TC
3. TM 根据 TC 中记录的全部事务分支执行情况 决定提交或者回滚。

Seata，在本地事务阶段，RM就已经执行了本地事务的提交操作，然后将执行后用来回滚的数据保存至 UNDO_LOG 。 若某个事务分支提交失败，TM再执行 回滚操作，将日志表里的数据回滚，所以TM的提交操作是不做真实的提交的，仅仅是删除 日志表中的记录。

既然本地事务已经提交如何做到 数据的隔离性？(Seata默认的事务隔离级别为 ReadUnCommit)
Seata AT模式
用户的sql被Seata代理所托管,Seata-AT模式能感知到用户的所有sql,并对之进行操作
Tx1 在一阶段本地事务提交前 要确保先拿到 全局锁 (行粒度) ，二阶段全局事务提交，才会释放全局锁
Tx2 在 Tx1 全局提交前 尝试拿到全局锁，重试等待，Tx1 全局释放。
如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。
此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。
整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写

Ps : Seata相关文档及下载地址
seata项目github地址：https://github.com/seata/seata
seata中间件下载地址：https://github.com/seata/seata/releases
seata中文官方文档：https://github.com/seata/seata/

2.3.2 SpringCloud + TX-LCN
实施方案

1. 下载https://github.com/codingapi/txlcn-demo TX事务服务, 创建表 t_tx_exception
2. 配置文件参考 https://www.txlcn.org/zh-cn/docs/setting/manager.html

pom.xml

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>cn.huanzi.qch.txlcn</groupId>
    <artifactId>txlcn-tm</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>txlcn-tm</name>
    <description>Tx-Manager(TM)，TX-LCN分布式事务框架的独立服务</description>

    <!--继承信息-->
    <parent>
        <groupId>cn.huanzi.qch</groupId>
        <artifactId>parent</artifactId>
        <version>1.0.0</version>
    </parent>

    <dependencies>
        <!-- 参照例子引入需要的依赖jar -->
        <dependency>
            <groupId>com.codingapi.txlcn</groupId>
            <artifactId>txlcn-tm</artifactId>
            <version>5.0.2.RELEASE</version>
        </dependency>

        <!-- text报错，添加一下依赖-->
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <!-- 构建工具 -->
    <build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
        </plugins>
        <finalName>txlcn-tm</finalName>
    </build>

</project>

application.xml

spring.application.name=txlcn-tm
server.port=7970

spring.datasource.driver-class-name=com.mysql.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/test?characterEncoding=UTF-8&serverTimezone=Asia/Shanghai
spring.datasource.username=root
spring.datasource.password=123456
spring.jpa.database-platform=org.hibernate.dialect.MySQL5InnoDBDialect
spring.jpa.hibernate.ddl-auto=validate

# TM后台登陆密码
tx-lcn.manager.admin-key=123456

tx-lcn.manager.host=127.0.0.1
tx-lcn.manager.port=8070

# 开启日志,默认为false
tx-lcn.logger.enabled=true
tx-lcn.logger.driver-class-name=${spring.datasource.driver-class-name}
tx-lcn.logger.jdbc-url=${spring.datasource.url}
tx-lcn.logger.username=${spring.datasource.username}
tx-lcn.logger.password=${spring.datasource.password}logging.level.com.codingapi.txlcn=DEBUG

#redis 主机
spring.redis.host=127.0.0.1
#redis 端口
spring.redis.port=6379
#redis 密码
spring.redis.password=

3. 在启动类添加注解 @EnableTransactionManagerServer

package cn.huanzi.qch.txlcn.tm;

import com.codingapi.txlcn.tm.config.EnableTransactionManagerServer;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
@EnableTransactionManagerServer
public class TxlcnTmApplication {

    public static void main(String[] args) {
        SpringApplication.run(TxlcnTmApplication.class, args);
}
}

4. 把我们的Redis服务运行起来，然后启动txlcn-tm，启动成功后访问tm后台管理系统，使用默认密码登录（可以配置登录密码），访问 http://127.0.0.1:7970/admin/index.html进入管理后台，默认密码是codingapi，我们这里配置了123456
5. Tx-Client :
   TC引入依赖

<dependency>
            <groupId>com.codingapi.txlcn</groupId>
            <artifactId>txlcn-tc</artifactId>
            <version>5.0.2.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>com.codingapi.txlcn</groupId>
            <artifactId>txlcn-txmsg-netty</artifactId>
            <version>5.0.2.RELEASE</version>
        </dependency>

配置文件添加
#是否启动LCN负载均衡策略(优化选项，开启与否，功能不受影响)

tx-lcn.ribbon.loadbalancer.dtx.enabled=true

#默认之配置为TM的本机默认端口

tx-lcn.client.manager-address=127.0.0.1:8070

#开启日志,默认为false

tx-lcn.logger.enabled=true
tx-lcn.logger.driver-class-name=${spring.datasource.driver-class-name}
tx-lcn.logger.jdbc-url=${spring.datasource.url}
tx-lcn.logger.username=${spring.datasource.username}
tx-lcn.logger.password=${spring.datasource.password}
logging.level.com.codingapi.txlcn=DEBUG

6. 在启动类上使用 @EnableDistributedTransaction
7. 提交本地事务的地方添加@LcnTransaction，分布式事务注解，PS：@LcnTransaction的target是在方法上的，@Target({ElementType.METHOD})

TX-LCN 不产生事务仅仅是对事务进行了分布式管理，最后附上一张简单易懂的 原理图：

分享学习大佬 https://blog.csdn.net/qq_37442469?t=1