从零开始 Spring Cloud 13：分布式事务

最新推荐文章于 2024-04-18 13:06:12 发布

魔芋红茶

最新推荐文章于 2024-04-18 13:06:12 发布

阅读量664

点赞数 2

分类专栏： JAVA 文章标签： spring cloud 分布式 seata

本文链接：https://blog.csdn.net/hy6533/article/details/133612640

版权

本文介绍了分布式事务的问题及其理论基础CAP和BASE，深入探讨了Seata事务协调者的作用和系统架构。通过示例项目展示了在分布式系统中，Seata提供的四种分布式事务模式：XA、AT、TCC和SAGA，分析了它们的优缺点。重点讲解了Seata的AT模式和TCC模式的实现细节，包括事务悬挂和空回滚的处理。

摘要由CSDN通过智能技术生成

从零开始 Spring Cloud 13：分布式事务

1.分布式事务问题

用一个示例项目演示在分布式系统中使用事务会产生的问题。

示例项目的 SQL：seata_demo.sql

示例项目代码：seata-demo.zip

这个示例项目中的微服务的互相调用依赖于 Nacos，所以还需要提供 Nacos。

整个项目的架构如下：

订单服务有一个创建订单接口，这个接口会在订单表中生成订单信息，同时会依次调用账户服务和库存服务，这两个微服务会分别扣减账户的金额以及扣减库存。

在执行接口的时候，如果库存足够（小于等于10），就可以正常生成订单并完成库存扣减。但如果库存不够，就会出现订单生成、金额扣减，但库存没有成功扣减的问题。

接口调用示例可以参考新建订单接口文档。

出现这个现象的原因是订单创建、金额扣减、库存扣减这三个动作分别属于三个微服务的事务，这三个事务之间没有联系，所以当其中一个事务失败回滚时，另外两个事务不会受到影响，所以会出现数据不一致的问题。

为了解决这个问题，我们需要一个在分布式系统之上协调各个微服务事务的统一事务机制。

2.理论基础

2.1.CAP 定理

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

Consistency（一致性）
Availability（可用性）
Partition tolerance （分区容错性）

关于分布式系统的一致性、可用性以及分区容错性的详细说明，可以观看这个视频。

对于任意的分布式系统，最多仅能同时满足这三个目标中的两个：

一般来说，由于分布式系统之间的通信必须通过网络连接，所以分区容错性（P）是不可避免的，所以一般的分布式系统要么会满足可用性和分区容错性（AP），要么会满足一致性和分区容错性（CP）。

2.2.BASE 理论

BASE 理论是现实中用 CAP 定理实现分布式系统时的一种指导思想，包含三个方面的内容：

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

BASE 理论可以看做是在具体工程实践中对 CAP 定理的一种妥协，即不需要提供完整系统的可用性，以及确保整个系统在任意时间都具备数据一致性。

从 BASE 理论可以派生出两种分布式事务的解决思路：

AP模式：各子事务分别执行和提交，允许出现结果不一致，然后采用弥补措施恢复数据即可，实现最终一致。
CP模式：各个子事务执行后互相等待，同时提交，同时回滚，达成强一致。但事务等待过程中，处于弱可用状态。

但不管是哪一种模式，都需要在子系统事务之间互相通讯，协调事务状态，也就是需要一个事务协调者(TC)：

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

3.Seata 介绍

官网地址：http://seata.io/

3.1.系统架构

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

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

架构图：

Seata基于上述架构提供了四种不同的分布式事务解决方案：

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

无论哪种方案，都离不开TC，也就是事务的协调者。

3.2.部署 TC 服务

部署 seata-tc 服务可以参考这篇文章。

4.实现分布式事务

4.1.XA 模式

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

4.1.1.两阶段提交

XA是规范，目前主流数据库都实现了这种规范，实现的原理都是基于两阶段提交。

正常情况：

异常情况：

一阶段：

事务协调者通知每个事物参与者执行本地事务
本地事务执行完成后报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库锁

二阶段：

事务协调者基于一阶段的报告来判断下一步操作
- 如果一阶段都成功，则通知所有事务参与者，提交事务
- 如果一阶段任意一个参与者失败，则通知所有事务参与者回滚事务

4.1.2.Seata 的 XA 模式

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

RM一阶段的工作：

① 注册分支事务到TC

② 执行分支业务sql但不提交

③ 报告执行状态到TC

TC二阶段的工作：

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

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

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

RM二阶段的工作：

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

4.1.3.优缺点

XA模式的优点：

事务的强一致性，满足ACID原则。
常用数据库都支持，实现简单，并且没有代码侵入

XA模式的缺点：

因为一阶段需要锁定数据库资源，等待二阶段结束才释放，性能较差
依赖关系型数据库实现事务

4.1.4.实现

在微服务配置文件 application.yml 中添加 Seata 的相关配置：

seata:
  data-source-proxy-mode: XA # 使用 XA 模式分布式事务

在分布式事务的入口方法上添加@GlobalTransactional注解：

@Slf4j
@Service
public class OrderServiceImpl implements OrderService {
   
	// ...
    @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();
    }
}

重启微服务并测试，可以观察到如果其中一个微服务执行失败，所有微服务的相关事务都会回滚，日志中会出现类似下面的信息：

io.seata.rm.AbstractRMHandler            : Branch Rollbacking: 192.168.0.46:8091:153565015951716362 153565015951716366 jdbc:mysql:///seata_demo

4.2.AT 模式

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

4.2.1.Seata 的 AT 模型

阶段一RM的工作：

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

阶段二提交时RM的工作：

删除undo-log即可

阶段二回滚时RM的工作：

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

4.2.2.AT 与 XA 的区别

XA模式一阶段不提交事务，锁定资源；AT模式一阶段直接提交，不锁定资源。
XA模式依赖数据库机制实现回滚；AT模式利用数据快照实现数据回滚。
XA模式强一致；AT模式最终一致

4.2.3.脏写问题

AT 模式虽然在性能上比 XA 模式更好，但问题是在隔离性上做了牺牲，所以可能会存在脏写问题，因此 AT 模式还引入了全局锁和更新后快照解决这个问题，具体可以观看这个视频。

4.2.4.实现

要实现 AT 模式，需要在 Seata 对应的数据库（seata）中添加一个管理全局锁的表：

DROP TABLE IF EXISTS `lock_table`;
CREATE TABLE `lock_table`  (
  `row_key` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `xid` varchar(96) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,