分布式事务-Seata-详细图文讲解

分布式事务问题

概述

一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题

现象

单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用，分别使用三个独立的数据源，
业务操作需要调用三个服务来完成。此时每个服务内部的数据一致性由本地事务来保证，但是全局的数据一致性问题没法保证。

Seata简介

Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。
官网：http://seata.io/zh-cn/

作用

分布式事务处理过程

一ID+三组件模型：
全局唯一事务ID：Transaction ID XID
三组件：

• Transaction Coordinator (TC)
  • 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚；
• Transaction Manager ™
  • 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议；
• Resource Manager (RM)
  • 控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚

处理过程

1. TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID；
2. XID 在微服务调用链路的上下文中传播；
3. RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖；
4. TM 向 TC 发起针对 XID 的全局提交或回滚决议；
5. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

发布说明: https://github.com/seata/seata/releases

使用

本地：@Transactional
全局：@GlobalTransactional

安装

下载

https://github.com/seata/seata/releases

解压+修改配置文件

seata-server-0.9.0.zip解压到指定目录并
修改conf目录下的file.conf配置文件

1. 先备份原始file.conf文件
2. 主要修改：自定义事务组名称+事务日志存储模式为db+数据库连接信息
3. file.conf
   1. service模块
   2. store模块

service {
 
  vgroup_mapping.my_test_tx_group = "fsp_tx_group"
 
  default.grouplist = "127.0.0.1:8091"
  enableDegrade = false
  disable = false
  max.commit.retry.timeout = "-1"
  max.rollback.retry.timeout = "-1"
}
1
2
3
4
5
6
7
8
9
10

 
## transaction log store
store {
  ## store mode: file、db
  mode = "db"
 
  ## file store
  file {
    dir = "sessionStore"
 
    # branch session size , if exceeded first try compress lockkey, still exceeded throws exceptions
    max-branch-session-size = 16384
    # globe session size , if exceeded throws exceptions
    max-global-session-size = 512
    # file buffer size , if exceeded allocate new buffer
    file-write-buffer-cache-size = 16384
    # when recover batch read size
    session.reload.read_size = 100
    # async, sync
    flush-disk-mode = async
  }
 
  ## database store
  db {
    ## the implement of javax.sql.DataSource, such as DruidDataSource(druid)/BasicDataSource(dbcp) etc.
    datasource = "dbcp"
    ## mysql/oracle/h2/oceanbase etc.
    db-type = "mysql"
    driver-class-name = "com.mysql.jdbc.Driver"
    url = "jdbc:mysql://127.0.0.1:3306/seata"
    user = "root"
    password = "你自己密码"
    min-conn = 1
    max-conn = 3
    global.table = "global_table"
    branch.table = "branch_table"
    lock-table = "lock_table"
    query-limit = 100
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

创建数据库

mysql数据库中新建库Seata

创建数据表

位置：建表db_store.sql在\seata-server-0.9.0\seata\conf目录里面
db_store.sql

修改配置文件

修改seata-server-0.9.0\seata\conf目录下的registry.conf配置文件

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"
 
  nacos {
    serverAddr = "localhost:8848"
    namespace = ""
    cluster = "default"
  }
}
1
2
3
4
5
6
7
8
9
10

目的是：指明注册中心为nacos，及修改nacos连接信息

启动

先启动Nacos端口号8848
再启动seata-server

异常

超时异常——没加@GlobalTransactional

故障分析

当库存和账户金额扣减后，订单状态并没有设置为已经完成，没有从零改为1
而且由于feign的重试机制，账户余额还有可能被多次扣减

解决异常

添加@GlobalTransactional

@GlobalTransactional(name = "fsp-create-order",rollbackFor = Exception.class)
public void create(Order order)
{
    。。。。。。
}
1
2
3
4
5
6

下单后数据库数据并没有任何改变
记录都添加不进来

部分补充

• 2019年1月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案
• Simple Extensible Autonomous Transaction Architecture，简单可扩展自治事务框架
• 2020起始，参加工作后用1.0以后的版本

再看TC/TM/RM三大组件

分布式事务的执行流程

• TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
• 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
• TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
• TC 汇总事务信息，决定分布式事务是提交还是回滚；
• TC 通知所有 RM 提交/回滚 资源，事务二阶段结束。

AT模式如何做到对业务的无侵入

前提

• 基于支持本地 ACID 事务的关系型数据库。
• Java 应用，通过 JDBC 访问数据库。

整体机制

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：
  • 提交异步化，非常快速地完成。
  • 回滚通过一阶段的回滚日志进行反向补偿。

一阶段加载

在一阶段，Seata 会拦截“业务 SQL”，
1 解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，
2 执行“业务 SQL”更新业务数据，在业务数据更新之后，
3 其保存成“after image”，最后生成行锁。
以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段提交

二阶段如是顺利提交的话，
因为“业务 SQL”在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚

二阶段回滚：
二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。
回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，
如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。