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

什么是分布式事务，什么是seata？

分布式事务就像是一家连锁店的多个分店同时参与一项促销活动，要确保所有分店的促销结果一致，即要么全部成功，要么全部撤销。在软件系统中，当多个独立的服务需要协同完成一项任务时，涉及到的数据更新必须保证要么都成功，要么都失败，确保整个系统的数据一致性。

Seata 就像是那个确保连锁店各分店促销一致性的协调者，它帮助构成微服务架构的各个服务保持事务一致，确保即使在不同服务间进行数据操作时，也能保证要么所有服务的操作都提交，要么都回滚，防止数据不一致的情况发生。

在Seata的事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

• RM (Resource Manager) - 资源管理器：管理分支事务，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

Seata的工作架构如图所示：

其中，TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。

而TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

部署TC服务

准备数据库表：

Seata支持多种存储模式，但考虑到持久化的需要，我们一般选择基于数据库存储sql文件：https://pan.baidu.com/s/15uSbxAEXv8RMdEhx5-_jaw?pwd=7633 
提取码：7633 

备配置文件：

其中包含了seata运行时所需要的配置文件：https://pan.baidu.com/s/1hdXJHT_D7E3L7KMIEEo22Q?pwd=7633 
提取码：7633 

Docker部署：

确保与MySQL，注册中心在同一个网络中，确保所在当前目录下有seata文件夹

docker run --name seata \
-p 8099:8099 \
-p 7099:7099 \
-e SEATA_IP=192.168.150.101 \
-v ./seata:/seata-server/resources \
--privileged=true \
--network 配置网络，与MySQL，注册中心在同一个 \
-d \
seataio/seata-server:1.5.2

微服务集成Seata

1、引入依赖

  <!--seata-->
  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
  </dependency>

2、修改配置（这一步可以用配置共享方便一些）

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    type: nacos # 注册中心类型 nacos
    nacos:
      server-addr: 192.168.150.101:8848 # nacos地址
      namespace: "" # namespace，默认为空
      group: DEFAULT_GROUP # 分组，默认是DEFAULT_GROUP
      application: seata-server # seata服务名称
      username: nacos
      password: nacos
  tx-service-group: hmall # 事务组名称
  service:
    vgroup-mapping: # 事务组与tc集群的映射关系
      hmall: "default"

3、添加数据库表

seata的客户端在解决分布式事务的时候需要记录一些中间数据，保存在数据库中。因此我们要要用到seata的微服务的数据库中添加这么一个表：

-- for AT mode you must to init this sql for you business database. the seata server not need it.
CREATE TABLE IF NOT EXISTS `undo_log`
(
    `branch_id`     BIGINT       NOT NULL COMMENT 'branch transaction id',
    `xid`           VARCHAR(128) NOT NULL COMMENT 'global transaction id',
    `context`       VARCHAR(128) NOT NULL COMMENT 'undo_log context,such as serialization',
    `rollback_info` LONGBLOB     NOT NULL COMMENT 'rollback info',
    `log_status`    INT(11)      NOT NULL COMMENT '0:normal status,1:defense status',
    `log_created`   DATETIME(6)  NOT NULL COMMENT 'create datetime',
    `log_modified`  DATETIME(6)  NOT NULL COMMENT 'modify datetime',
    UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE = InnoDB
  AUTO_INCREMENT = 1
  DEFAULT CHARSET = utf8mb4 COMMENT ='AT transaction mode undo table';

Seata的使用

非常简单，做完上述配置后，只需要在需要开启分布式事务的方法上添加@GlobalTransactional注解即开一键开启分布式事务

分布式事务解决方案：

Seata支持四种不同的分布式事务解决方案：

• XA

• TCC

• AT

• SAGA

这里我们以XA模式和AT模式来给大家讲解其实现原理。

XA模式

XA 规范 是 X/Open 组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准，XA 规范 描述了全局的TM与局部的RM之间的接口，几乎所有主流的数据库都对 XA 规范 提供了支持。

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型，基本架构如图：

RM一阶段的工作：

1. 注册分支事务到TC

2. 执行分支业务sql但不提交

3. 报告执行状态到TC

TC二阶段的工作：

1. TC检测各分支事务执行状态

   1. 如果都成功，通知所有RM提交事务

   2. 如果有失败，通知所有RM回滚事务

RM二阶段的工作：

• 接收TC指令，提交或回滚事务

优缺点

XA模式的优点是什么？

• 事务的强一致性，满足ACID原则

• 常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点是什么？

• 因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差

• 依赖关系型数据库实现事务

实现步骤

修改配置

seata:
  data-source-proxy-mode: XA

AT模式

AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。

基本流程图：

阶段一RM的工作：

• 注册分支事务

• 记录undo-log（数据快照）

• 执行业务sql并提交

• 报告事务状态

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

• 根据undo-log恢复数据到更新前

AT与XA的区别

简述AT模式与XA模式最大的区别是什么？

• XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。

• XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。

• XA模式强一致；AT模式最终一致

可见，AT模式使用起来更加简单，无业务侵入，性能更好。因此企业90%的分布式事务都可以用AT模式来解决。

实现步骤

 修改配置即可