分布式事务

最新推荐文章于 2024-01-12 19:53:21 发布

啵萝蜜多斩

最新推荐文章于 2024-01-12 19:53:21 发布

阅读量291

点赞数

分类专栏：微服务文章标签：分布式微服务

本文链接：https://blog.youkuaiyun.com/oybc666/article/details/128980920

版权

微服务专栏收录该内容

4 篇文章

订阅专栏

文章详细介绍了分布式事务的ACID特性、CAP定理以及在分布式系统中的一致性和可用性权衡。接着，重点讲解了Seata这一分布式事务解决方案，包括其架构、提供的四种事务模式（XA、TCC、AT、SAGA）以及各种模式的优缺点。最后提到了Seata在微服务集成中的使用和配置，并讨论了分布式锁的实现策略。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

单机事务的特性（ACID）：

原子性 A：事务中的所有操作，要么全部成功，要么全部失败

一致性 C：要保证数据库内部的完整性约束，声明性约束

隔离性 I：对同一资源操作的事务不能同时发生

持久性 D：对数据库做的一切修改将永久保存，不管是否出现故障

分布式事务

集成服务、或集成数据库架构下，产生的事务

CAP定理

分布式系统的三个指标：

Consistency 一致性

Availability 可用性

Partition tolerance 分区容错性

该三个指标不可能同时做到

一致性-Consistency : 用户访问分布式系统中的任意节点，得到的数据必须一致

可用性 - Availability：用户访问集群中的任意健康节点，必须能得到响应，而不是超时或拒绝

分区容错性 - Partition Tolerance : 因为网络故障或其他原因导致分布式系统中的部分节点与其他节点失去连接，形成独立分区，在集群出现分区时，整个系统也要持续对外提供服务

CAP 定理中存在的问题

在分布式系统中，各个微服务之间的网络不能保证绝对的健康，必然会有出现故障的情况，因此分区容错性（ P T）是不可避免的，
如果此时要保证一致性（A），服务就会处于阻塞状态，等待网络恢复，完成数据同步才能继续对外提供服务支持，在这期间就处于不可用，就无法实现可用性（C）
如果此时要保证可用性（C），那出现的分区数据就无法同步，就无法实现数据的一致性（A）
总的来说，A 和 C 二者在出现 P 的情况下，只能实现其中的一个

BASE 理论

BASE 理论是对 CAP 的一种解决思路，它包含了三个思想

基本可用-Basically Available

分布式系统出现故障时，允许损失部分可用性，即保证核心可用

软状态-Soft State

在一定时间内，允许出现中间状态，比如临时的数据不一致

最终一致性-Eventually Consistent

虽然无法保证强一致性，但是在软状态结束后，最终达到数据一致

解决分布式事务的思路

两种思路

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

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

tips : 子事务系统，称为分支事务，有关联的各个分支事务在一起，称为全局事务 Global Transaction

事务协调者（TC，seata中的概念）

在 AP ,CP 两种模式，都需要在子事务之间相互通讯，协调事务状态，

Seata

seata 是蚂蚁金服和阿里巴巴共同开源的分布式事务解决方案，致力于事务的高性能、简单易用

官网地址： http://seata.io/ ，其中的文档、博客中提供了大量的使用说明、源码分析。

架构

三大角色

Transaction Coordinator （TC）：事务协调者

维护全局和分支事务的状态，协调全局事务的提交或回滚

Transaction Manager （TM）：事务管理器

定义全局事务的范围、开始全局事务、提交或回滚全局事务

Resource Manager（RM）：资源管理器

管理分支事处理的资源，与TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚

架构图如下

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

XA 模式：强一致性分阶段事务模式，牺牲了一定的可用性，无业务入侵

TCC 模式：最终一致的分阶段事务模式，有业务入侵

AT 模式：最终一致的分阶段事务模式，无业务入侵，也是 Seata 的默认模式

SAGA 模式：长事务模式，有业务入侵

以上方案都与事务协调者（TC）关联

微服务集成Seata

引入依赖：

<!--seata-->
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <exclusions>
        <!--版本较低，1.3.0，因此排除--> 
        <exclusion>
            <artifactId>seata-spring-boot-starter</artifactId>
            <groupId>io.seata</groupId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <!--seata starter 采用1.4.2版本-->
    <version>${seata.version}</version>
</dependency>

配置TC地址：

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

namespace为空，就是默认的public

结合起来，TC服务的信息就是：public@DEFAULT_GROUP@seata-tc-server@SH，这样就能确定TC服务集群了。然后就可以去Nacos拉取对应的实例信息了。

XA 模式

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

XA 的两个阶段

第一阶段：

事务协调者通知每个事务参与者执行本地事务

本地事务执行完成后，报告事务执行状态给事务协调者，此时事务不提交，继续持有数据库的锁

第二阶段：

事务协调者基于第一阶段的报告来判断下一步操作

如果一阶段都成功，则通知所有事务参与者，提交事务

如果一阶段任意一个参与者失败，则通知所有的事务参与者回滚事务

Seata的XA模型

Seata对原始的XA模式做了简单的封装和改造，以适应自己的事务模型

RM 一阶段的工作：

注册分支事务到 TC

执行分支业务SQL但不提交

报告执行状态到TC

TC 二阶段的工作：

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

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

如果有失败，通知所欲哦RM 回滚事务

RM 二阶段的工作：

接收TC 的失灵，提交或回滚事务

XA 模式的优缺点

优点：

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

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

缺点：

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

依赖于关系型数据库的事务

项目中的使用

配置application.yml

seata:
  data-source-proxy-mode: XA

给发起全局事务的入口方法添加注解：@GlobalTransaction

AT模式

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

AT 模式需要一个表来记录全局锁，另一张表来记录数据快照 undo-log

流程图

RM 的工作流程：

阶段一：

注册分支事务

记录undo-log（数据快照）：RM 拦截业务的SQL获取条件，并执行查询，将结果记录为快照

执行业务SQL 并提交

报告事务状态

阶段二：

提交时，删除 undo-log

回滚时，根据 undo-log 恢复数据到更新前

面试题：

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

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

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

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

脏写问题

在多线程并发访问 AT 模式的分布式事务时，有可能出现脏写问题，即同一时刻有别的事务操作当前正在操作的数据

解决方式：

引入全局锁，在释放DB锁之前，拿到全局锁，使目标数据只允许一个事务操作

AT模式的优缺点

优点：

第一阶段完成，直接提交事务，释放数据库资源，性能较好

利用全局锁，实现读写隔离

没有代码侵入，框架自动完成回滚和提交

缺点：

两阶段之间属于软状态，属于最终一致

框架的快照功能会影响性能，但比 XA 模式要好很多

项目中的使用

配置 application.yml （Seata 模式默认就是 AT模式）

seata:
  data-source-proxy-mode: AT # 默认就是AT

TCC 模式

TCC 模式与 AT 模式相似，每阶段都是独立事务，不同的是 TCC 通过人工编码来实现数据恢复

需实现三个方法：

try : 资源的检测与预留

Confirm：完成资源操作业务，要求 try 成功 Confirm 一定成功

Cancel ：预留资源释放，可以理解为 try 的反向操作

TCC 事务模型

通过例子了解 TCC 模式的流程

优缺点

优点：

一阶段完成直接提交事务，释放数据资源，性能好

相比 AT 模型，无需生成快照，无需使用全局锁，性能最强

不依赖数据库事务，而是依赖补偿操作，可以用于非事务数据库

缺点：

有代码侵入，需要人为编写 try、Confirm 和 Cancel 接口

软状态、事务时最终一致

需要考虑 Confirm 和 Canel 的失败情况做好幂等处理

事务悬挂和空回滚

空回滚

当某分支事务的try阶段阻塞时，可能导致全局事务超时而触发阶段二的 cancel 操作，在未执行 try 操作时先执行了 calcel 操作，这时 cancel 不能回滚，就是空回滚

执行 cancel 操作时，应该判断try是否已经执行，如果尚未执行，则应该空回滚

业务悬挂

对于已经空回滚的业务，之前被阻塞的try 操作恢复，继续执行try ,就永远不可能confirm 或 cancel，事务一致处于中间状态，这就是业务悬挂，

执行try操作时，应当判断cancel 是否已经执行过了，如果已经执行，应当阻止空回滚后的 try 操作，避免悬挂

TCC模式的实现

通过记录当前事务状态，根据事务的状态对症解决

定义记录事务状态的表

xid：是全局事务的ID

freeze_money：用来记录用户冻结金额 (以更改金额为例)

state：记录事务状态

声明 TCC 接口注解：@LocalTCC

@LocalTCC
public interface AccountTCCService {

    // 根据用户ID 更改金额
    @TwoPhaseBusinessAction(name = "deduct", 
                        commitMethod = "confirm", 
                            rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money")int money);

    // 根据 全局事务 ID 删除 记录信息，
    boolean confirm(BusinessActionContext ctx);
    // 根据 全局事务 ID 回滚修改的金额，并修改全局事务的当前状态
    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();
        // 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);

        // 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;
    }
}

逻辑：