分布式事务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交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

生命周期

TM 向 TC 申请开启一个全局事务，TC 创建全局事务后返回全局唯一的 XID，XID 会在全局事务的上下文中传播；

RM 向 TC 注册分支事务，该分支事务归属于拥有相同 XID 的全局事务；

TM 向 TC 发起全局提交或回滚；

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模式脏写问题

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

AT模式的写隔离

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

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

AT模式优点

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

AT模式缺点

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

TCC模式

TCC模式原理

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

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

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

TCC优点

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

TCC缺点

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

TCC的空回滚和业务悬挂

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

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

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"
  }
}

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端口上

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

分布式事务典型场景

如何解决分布式事务问题

CAP定理

BASE理论

架构

生命周期

解决方案

XA模式

AT模式

TCC模式

Sega模式

四种模式对比

部署TC服务器

分布式服务案例

XA模式下代码

AT模式下代码

TCC模式下代码

TC异地多机房容灾架构

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

相关文章

发布评论取消回复

竹子爱熊猫

服务器开放端口，服务器开放端口的步骤

百度搜索：蓝易云 – docker部署jenkins修改登录会话超时时间教程

27 期 | 死锁（3）解决死锁

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

分布式事务典型场景

如何解决分布式事务问题

CAP定理

BASE理论

架构

生命周期

解决方案

XA模式

AT模式

TCC模式

Sega模式

四种模式对比

部署TC服务器

分布式服务案例

XA模式下代码

AT模式下代码

TCC模式下代码

TC异地多机房容灾架构

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

相关文章

发布评论 取消回复

竹子爱熊猫

服务器开放端口，服务器开放端口的步骤

百度搜索：蓝易云 – docker部署jenkins修改登录会话超时时间教程

27 期 | 死锁（3）解决死锁

发布评论取消回复