分布式事务seata从入门到实践

前言

为什么考虑做一期这样的总结呢，主要时当前内卷的大背景下，到不管是小公司还是大厂，即使内部不一定涉及分布式事务，但是面试时也必然会问。如果不懂，基本就被pass掉，因此决心好好研究一番，挑选了星级比较高的分布式事务中间件seata，说不定未来的工作中能用到。下文借鉴了黑马b站的视频，觉得讲得不错，因此基于他的大纲做的总结。

事务

事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

原子性（atomicity）：个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被观察到的。

隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务 是隔离的，并发执行的各个事务之间不能互相干扰。隔离性又分为四个级别：读未提交(read uncommitted)、读已提交 (read committed，解决脏读)、可重复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。

持久性（durability）：指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。

分布式事务

在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有的分支事务状态一致。

分布式事务典型场景

• 跨库事务
  跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。

• 分库分表
• 服务化
  微服务架构是目前一个比较一个比较火的概念。也是分布式事务应用最多的场景，独立服务之间通过RPC框架来进行远程调用，实现彼此通信。

如何解决分布式事务问题

• 分析产生原因
  跨服务、跨数据源场景
• 理解理论基础
  思考解决分布式事务的基本思路
• 弄清原理
  了解seata框架，学习seata原理
• 动手实践
  利用seata解决分布式事务问题

理论基础

CAP定理

1988年，加州大学的计算机科学家Eirc Brewer提出，分布式系统有三个指标：

• Consistency（一致性）
  用户访问分布式系统中的任意节点，得到的数据必须一致
• Availability（可用性）
  用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝
• Partition tolerance（分区容错性）
  Eric Brewer 说，分布式系统无法同时满足这三个指标。这个结论就叫做 CAP 定理。

BASE理论

BASE理论是对CAP的一种解决思路，包含三个思想：
Basically Available （基本可用） ：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
Soft State（软状态） ：在一定时间内，允许出现中间状态，比如临时的不一致状态。
Eventually Consistent（最终一致性） ：虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致。

而分布式事务最大的问题是各个子事务的一致性问题，因此可以借鉴CAP定理和BASE理论：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。

CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

分布式事务模型

解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。

这里的子系统事务，称为分支事务 ；有关联的各个分支事务在一起称为全局事务。

解决分布式事务的思想

• 最终一致思想：各分支事务分别执行并提交，如果有不一致的情况，再想办法恢复数据
• 强一致思想：各分支事务执行完业务不要提交，等待彼此结果。而后统一提交或回滚

seata

Seata是 2019 年 1 月份蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案。致力于提供高性能和简单易用的分布式事务服务，为用户打造一站式的分布式解决方案。

官网地址:
seata.io/zh-cn/

架构

seata事务管理中有三个重要角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

生命周期

1. TM 向 TC 申请开启一个全局事务，TC 创建全局事务后返回全局唯一的 XID，XID 会在全局事务的上下文中传播；
2. RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务；
3. TM 向 TC 发起全局提交或回滚；
4. TC 调度 XID 下的分支事务完成提交或者回滚。

解决方案

• XA模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务侵入
• TCC模式：最终一致的分阶段事务模式，有业务侵入
• AT模式：最终一致的分阶段事务模式，无业务侵入，也是Seata的默认模式
• SAGA模式：长事务模式，有业务侵入

XA模式

什么是XA模式

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

什么是seata XA模式

在 Seata 定义的分布式事务框架内，利用事务资源（数据库）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种 事务模式。

RM一阶段的工作：

1、注册分支事务到TC。

2、执行业务SQL，但不提交。

3、报告执行状态到TC。

TC二阶段的工作：

• TC检测各事务的执行状态
  如果都成功，通知所有RM提交事务。
  如果有失败，通知所有RM回滚事务。

RM二阶段的工作：

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

XA模式的优点？

1、事务的强一致性，满足ACID原则。

2、常用的数据库都支持，实现简单，且没有代码侵入。

XA模式的缺点？

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

2、依赖关系型数据库实现事务。

AT模式

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

阶段一RM的工作：

• 注册分支事务
• 记录undo-log（快照数据）
• 执行业务SQL并提交
• 报告事务状态

阶段二提交时RM的工作：

• 删除undo-log即可

阶段二回滚时RM的工作：

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

AT模式原理

例如，一个分支业务的SQL如下：update tb_account set money = money - 10 where id = 1;

XA模式和AT模式的区别？

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

2、XA模式利用数据库机制实现回滚；AT模式利用数据快照机制实现回滚。

3、XA模式强一致；AT模式最终一致。

AT模式脏写问题

AT模式的写隔离

AT模式优点

• 一阶段直接完成事务提交，释放数据库资源，性能比较好
• 利用全局锁实现读写隔离
• 没有代码侵入，框架自动完成提交和回滚

AT模式缺点

• 两阶段间属于软状态，属于最终一致
• 框架的快照功能会影响性能，但是XA模式要好很多

TCC模式

TCC模式原理

TCC模式与AT模式非常相似，每阶段都是独立事务，不同的是TCC通过人工编码来实现数据恢复。需要实现三个方法：

• Try：资源的检测和预留。
• Confirm：完成资源操作业务；要求Try成功Confirm一定要成功。
• Cancel：预留资源释放，可以理解为Try的反向操作。

TCC优点

• 一阶段完成直接提交事务，释放数据库资源，性能好
• 相比AT模型，无需生成快照，无需使用全局锁，性能最强
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库

TCC缺点

• 有代码侵入，需要人为编写try、confirm和cancel接口，太麻烦
• 软状态，事务最终一致
• 需要考虑confirm和cancel的失败情况，做好幂等处理

TCC的空回滚和业务悬挂

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发二阶段的cancel操作。在未执行try操作时先执行了cancel操作，这时的cancel不能做回滚，就是空回滚。对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂

Sega模式

Sega模式是Seata提供的长事务解决方案。也分为两个阶段：

• 一阶段：直接提交本地事务
• 二阶段：成功什么都不做；失败则通过编写补偿业务来回滚

Sega模式优点

• 事务参与者可以通过事件驱动实现异步调用，吞吐高
• 一阶段直接提交事务，无锁，性能好
• 不用编写TCC的三个阶段，实现简单

Sega模式缺点

• 软状态持续事件不稳定，时效性差
• 没有锁，没有事务隔离，会有脏写

四种模式对比

	XA	AT	TCC	SAGA
一致性	强一致	弱一致	弱一致	最终一致
隔离性	完全隔离	基于全局锁隔离	基于资源预留隔离	无隔离
代码侵入	无	无	有，要编写三个接口	有，要编写状态机和补偿业务
性能	差	好	非常好	非常好
场景	对一致性、隔离性有高要求的业务	基于关系型数据库的大多数分布式事务场景都可以	1、对性能要求比较高的事务 2、有非关系型数据库参与的事务	1、业务流程长、业务流程多

部署TC服务器

• 下载seata-server安装包 下载地址：
  github.com/seata/seata...

• 修改配置文件

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos" #注册中心选择nacos

  nacos {
    application = "seata-tc-server" #seata-server应用名
    serverAddr = "127.0.0.1:8848" #nacos服务地址
    group = "DEFAULT_GROUP" #分组
    namespace = "" #namespace，不填，默认放置public分组下
    cluster = "CS" #集群
    username = "nacos" #用户名
    password = "nacos" #密码
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "nacos" #配置中心选择nacos

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties" #配置文件名称，需要提前在nacos配置列表导入
  }
}

• nacos导入配置文件

# 数据存储方式，db代表数据库

store.mode=db

store.db.datasource=druid

store.db.dbType=mysql

store.db.driverClassName=com.mysql.jdbc.Driver

store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true

store.db.user=root

store.db.password=****

store.db.minConn=5

store.db.maxConn=30

store.db.globalTable=global_table

store.db.branchTable=branch_table

store.db.queryLimit=100

store.db.lockTable=lock_table

store.db.maxWait=5000

# 事务、日志等配置

server.recovery.committingRetryPeriod=1000

server.recovery.asynCommittingRetryPeriod=1000

server.recovery.rollbackingRetryPeriod=1000

server.recovery.timeoutRetryPeriod=1000

server.maxCommitRetryTimeout=-1

server.maxRollbackRetryTimeout=-1

server.rollbackRetryTimeoutUnlockEnable=false

server.undo.logSaveDays=7

server.undo.logDeletePeriod=86400000

# 客户端与服务端传输方式

transport.serialization=seata

transport.compressor=none

# 关闭metrics功能，提高性能

metrics.enabled=false

metrics.registryType=compact

metrics.exporterList=prometheus

metrics.exporterPrometheusPort=9898

• 创建seata数据库，初始化数据

-- -------------------------------- The script used when storeMode is 'db' --------------------------------
-- the table to store GlobalSession data
CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR(128) NOT NULL,
    `transaction_id`            BIGINT,
    `status`                    TINYINT      NOT NULL,
    `application_id`            VARCHAR(32),
    `transaction_service_group` VARCHAR(32),
    `transaction_name`          VARCHAR(128),
    `timeout`                   INT,
    `begin_time`                BIGINT,
    `application_data`          VARCHAR(2000),
    `gmt_create`                DATETIME,
    `gmt_modified`              DATETIME,
    PRIMARY KEY (`xid`),
    KEY `idx_gmt_modified_status` (`gmt_modified`, `status`),
    KEY `idx_transaction_id` (`transaction_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

-- the table to store BranchSession data
CREATE TABLE IF NOT EXISTS `branch_table`
(
    `branch_id`         BIGINT       NOT NULL,
    `xid`               VARCHAR(128) NOT NULL,
    `transaction_id`    BIGINT,
    `resource_group_id` VARCHAR(32),
    `resource_id`       VARCHAR(256),
    `branch_type`       VARCHAR(8),
    `status`            TINYINT,
    `client_id`         VARCHAR(64),
    `application_data`  VARCHAR(2000),
    `gmt_create`        DATETIME(6),
    `gmt_modified`      DATETIME(6),
    PRIMARY KEY (`branch_id`),
    KEY `idx_xid` (`xid`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

-- the table to store lock data
CREATE TABLE IF NOT EXISTS `lock_table`
(
    `row_key`        VARCHAR(128) NOT NULL,
    `xid`            VARCHAR(128),
    `transaction_id` BIGINT,
    `branch_id`      BIGINT       NOT NULL,
    `resource_id`    VARCHAR(256),
    `table_name`     VARCHAR(32),
    `pk`             VARCHAR(36),
    `gmt_create`     DATETIME,
    `gmt_modified`   DATETIME,
    PRIMARY KEY (`row_key`),
    KEY `idx_branch_id` (`branch_id`)
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8;

• windows环境下启动seata

直接运行seata-server.bat即可

注册成功后，nacos服务列表可以查看到seata-tc-server服务

分布式服务案例

微服务下单业务，在下单时会调用订单服务，创建订单并写入数据库。然后订单服务调用账户服务和库存服务：

• 账户服务负责扣减用户余额
• 库存服务负责扣减商品库存

项目架构大致如下：

XA模式下代码

• 订单服务（order-service）核心业务代码如下：

@Override
@GlobalTransactional // 开启全局事务
public Long create(Order order) {
    // 创建订单
    orderMapper.insert(order);
    try {
        // 扣用户余额
        accountClient.deduct(order.getUserId(), order.getMoney());
        // 扣库存
        storageClient.deduct(order.getCommodityCode(), order.getCount());

    } catch (FeignException e) {
        log.error("下单失败，原因:{}", e.contentUTF8(), e);
        throw new RuntimeException(e.contentUTF8(), e);
    }
    return order.getId();
}

• 账户服务（account-service）核心业务代码如下：

@Override
@Transactional
public void deduct(String userId, int money) {
    log.info("开始扣款");
    try {
        accountMapper.deduct(userId, money);
    } catch (Exception e) {
        throw new RuntimeException("扣款失败，可能是余额不足！", e);
    }
    log.info("扣款成功");
}

• 库存服务（storage-service）核心业务代码如下：

@Transactional
@Override
public void deduct(String commodityCode, int count) {
    log.info("开始扣减库存");
    try {
        storageMapper.deduct(commodityCode, count);
    } catch (Exception e) {
        throw new RuntimeException("扣减库存失败，可能是库存不足！", e);
    }
    log.info("扣减库存成功");
}

• 表结构如下：

• 服务注册至TC：
  application.yml配置seata相关信息，各个服务配置一样，仅展示其中一个

seata:
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server
      username: nacos
      password: nacos
  tx-service-group: seata-demo #事务组
  service:
    vgroup-mapping:
      seata-demo: CS #对应的集群名
  data-source-proxy-mode: XA #seata模式设置为AT，如果要使用XA模式，仅修改此处即可

• 服务注册至TC成功后，TC控制台会输出对应的日志信息：

• 测试

前置条件：用户余额1000元，商品库存10个

正常场景：

下单3个商品，总金额300元，预期是余额减300，库存减3，生成订单记录

调用成功，查看数据库记录。

余额成功扣减

生成订单记录

商品库存减3

异常场景：

下单100个，超出剩余库存，预期是余额不变，库存不变，订单记录未生成，至此分布式事务生效；

余额不变：

新的订单记录未生成：

库存不变：

AT模式下代码

• yml修改seata模式

data-source-proxy-mode: AT

• 业务表新增undo_log表

CREATE TABLE `undo_log` (
  `branch_id` bigint(20) 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 DEFAULT CHARSET=utf8 COMMENT='AT transaction mode undo table';

• 其余保持不变

TCC模式下代码

• 仅改造账户服务核心业务为tcc模式，核心业务代码如下：

@LocalTCC
public interface AccountTCCService {

    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money") int money);

    boolean confirm(BusinessActionContext ctx);

    boolean cancel(BusinessActionContext ctx);
}

@Service
@Slf4j
public class AccountTCCServiceImpl implements AccountTCCService {

    @Autowired
    private AccountMapper accountMapper;
    @Autowired
    private AccountFreezeMapper freezeMapper;

    @Override
    @Transactional
    public void deduct(String userId, int money) {
        // 0.获取事务id
        String xid = RootContext.getXID();

        // 悬挂业务，判断冻结是否已经被取消过了，取消过了无需再锁定资源
        AccountFreeze accountFreeze = freezeMapper.selectById(xid);
        if (Objects.nonNull(accountFreeze)) {
            return;
        }

        // 1.扣减可用余额
        accountMapper.deduct(userId, money);
        // 2.记录冻结金额，事务状态
        AccountFreeze freeze = new AccountFreeze();
        freeze.setUserId(userId);
        freeze.setFreezeMoney(money);
        freeze.setState(AccountFreeze.State.TRY);
        freeze.setXid(xid);
        freezeMapper.insert(freeze);
    }

    @Override
    public boolean confirm(BusinessActionContext ctx) {
        // 1.获取事务id
        String xid = ctx.getXid();
        // 2.根据id删除冻结记录
        int count = freezeMapper.deleteById(xid);
        return count == 1;
    }

    @Override
    public boolean cancel(BusinessActionContext ctx) {
        // 0.查询冻结记录
        String xid = ctx.getXid();
        AccountFreeze freeze = freezeMapper.selectById(xid);

        // 防止空回滚 try阶段发生异常，未冻结
        if (Objects.isNull(freeze)) {
            // 创建一笔空回滚的记录
            AccountFreeze accountFreeze = new AccountFreeze();
            accountFreeze.setXid(xid);
            accountFreeze.setFreezeMoney(0);
            accountFreeze.setUserId(ctx.getActionContext("userId").toString());
            accountFreeze.setState(AccountFreeze.State.CANCEL);
            freezeMapper.insert(accountFreeze);
            return true;
        }

        // 幂等处理
        if (freeze.getState() == AccountFreeze.State.CANCEL) {
            return true;
        }

        // 1.恢复可用余额
        accountMapper.refund(freeze.getUserId(), freeze.getFreezeMoney());
        // 2.将冻结金额清零，状态改为CANCEL
        freeze.setFreezeMoney(0);
        freeze.setState(AccountFreeze.State.CANCEL);
        int count = freezeMapper.updateById(freeze);
        return count == 1;
    }
}

TC异地多机房容灾架构

TC服务作为seata的核心服务，一定要保证高可用和异地容灾。

搭建TC的高可用和异地容灾

• 计划两台seata的tc服务节点

节点名称	IP地址	端口号	集群名称
seata	127.0.0.1	8091	CS
seata1	127.0.0.1	8092	SZ

之前我们已经启动了一台seata服务器，端口号是8091，集群名为CS。

现在将seata的目录复制一份，改名为seata2

修改seata1/conf/registry.conf文件内容如下：

registry {
  # file 、nacos 、eureka、redis、zk、consul、etcd3、sofa
  type = "nacos"

  nacos {
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SZ"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # file、nacos 、apollo、zk、consul、etcd3
  type = "nacos"

  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}

• 进入seata1/bin目录，执行

seata-server.bat -p 8092

• 打开nacos控制台，查看服务列表

点开详情

• nacos新增配置

• 修改每一个微服务的yml，将事务组映射到nacos

seata:
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server
      username: nacos
      password: nacos
  tx-service-group: seata-demo
  data-source-proxy-mode: AT
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      username: nacos
      password: nacos
      group: SEATA_GROUP
      data-id: client.properties

• 重启微服务，观察到底连接TC的CS/SZ集群，由client.properties里面的配置决定

如果集群是CS，则注册到TC 8091端口上

如果集群是SZ，则注册到TC 8092端口上