开发者

关于Seata基本使用及二阶提交流程

开发者 https://www.devze.com 2025-04-10 11:38 出处:网络 作者: Xwzzz_
目录一,Seata 的基本使用二,Seata 的工作原理二阶段提交(2PC)过程三,Seata 的四种事务模式1. AT 模式(自动事务模式)2. TCC 模式(Try-Confirm-Cancel)3. SAGA 模式4. XA 模式(原生分布式事务)总结一,Seat
目录
  • 一,Seata 的基本使用
  • 二,Seata 的工作原理
    • 二阶段提交(2PC)过程
  • 三,Seata 的四种事务模式
    • 1. AT 模式(自动事务模式)
    • 2. TCC 模式(Try-Confirm-Cancel)
    • 3. SAGA 模式
    • 4. XA 模式(原生分布式事务)
  • 总结

    一,Seata 的基本使用

    环境搭建

    • 下载 Seata:可以从 Seata 官网 或者 github 上获取最新版本。
    • 启动 Seata Server:下载 Seata 后,配置并启动 Seata Server,Seata 提供了一个默认的 Nacos 配置中心,也可以使用其他配置中心。

    引入依赖

    • 在微服务应用中,可以通过 Maven 或 Gradle 引入 Seata 的相关依赖。
    <dependency>
        <groupId>io.seata</groupId>
        <artifactId>seata-spring-boot-starter</artifactId>
        <version>1.6.1</version> <!-- 根据需要选择最新版本 -->
    </dependency>

    配置 Seata

    • 在使用全局事务之前,需要确保 Seata Server 已经启动,并且应用程序的 application.yml 配置正确
    seata:
      tx-service-group: my_test_tx_group  # 事务分组
      service:
        vgroup-mapping:
          my_test_tx_group: default
        enable-auto-data-source-proxy: true  # 自动代理数据源
      registry:
        type: nacos  # 注册中心类型
        nacos:
          server-addr: 127.0.0.1:8848  # Nacos 地址
          namespace: public
          group: SEATA_GROUP
      config:
        type: nacos
        nacos:
          server-addr: 127.0.0.1:8848
          namespace: public
          group: SEATA_GROUP

    在全局事务中使用 @GlobalTransactional

    • 全局事务的控制需要在方法上添加 @GlobalTransactional,以确保该方法及其调用的所有子事务受 Seata 统一管理。
    import io.seata.spring.annotation.GlobalTransactional;
    import org.springframework.stereotype.Service;
    import org.springframework.beans.factory.annotation.Autowired;
    
    @Service
    public class OrderService {
    
        @Autowired
        private StockService stockService;
    
        @Autowired
        private PaymentService paymentService;
    
        @GlobalTransactional(name = "order-create", rollbackFor = Exception.class)
        public void createOrder(String userId, String productId, int amount) {
            // 扣减库存
            stockService.deductStock(productId, amount);
    
            // 处理支付
            paymentService.processPayment(userId, amount);
    
            // 插入订单记录
            System.out.println("订单创建成功!");
        }
    }

    在分支事务中使用 @Transactional

    • Seata 在全局事务中,所有数据库操作会自动成为分支事务。
    • StockService 中:
    import org.springframework.stereotype.Service;
    import org.springframework.transaction.annotation.Transactional;
    
    @Service
    public class StockService {
    
        @Trandroidansactional
        public void deductStock(String productId, int amount) {
            // 执行数据库库存扣减操作
            System.out.println("库存扣减成功!");
        }
    }

    虽然 StockService 仍然使用的是本地事务 @Transactional,但因@GlobalTransactional 处于全局事务上下文中,Seata 会自动代理并管理它的事务

    二,Seata 的工作原理

    Seata 通过引入 全局事务管理分支事务 来解决分布式系统中的事务一致性问题。

    它使用类似于传统数据库事务中的 二阶段提交(2PC,Two-Phasphpe Commit) 协议来确保事务的原子性。

    二阶段提交(2PC)过程

    Seata 采用二阶段提交协议(2PC)来确保分布式事务的一致性。以下是二阶段提交的详细流程:

    1. 第一阶段:事务预备(Try阶段)

    • 全局事务开始:客户端应用向 Seata Server 发起请求,Seata 会生成一个全局事务 ID(XID),并返回给客户端应用。全局事务标识用于追踪整个分布式事务。
    // 启动全局事务
    GlobalTransaction tx = GlobalTransactionContext.getCurrentOrCreate();
    tx.begin();
    • 分支事务注册:每个参与者(微服务)启动后,会向 Seata Server 注册自己作为一个分支事务,Seata Server 会为每个分支事务分配一个唯一的事务分支 ID(Branch ID)。
    • Try 阶段:每个微服务会执行 Try 操作,即准备执行本地事务操作,但不提交数据。例如,更新某个数据库中的记录,但不提交。
    • 执行数据库操作:每个参与的子事务都会执行数据库更新,但不会真正提交,而是进入 prepare 状态(对于 AT 模式,这意味着生成 undo_log)。

    2. 第二阶段:提交(Commit)或回滚(Rollback)

    提交(Commit)

    • Seata Server 收到全局事务提交请求后,通知所有分支事务提交事务。
    • 分支事务提交数据库操作(删除 undo_log)。

    回滚(Rollback)

    • 如果 Seata Server 发现某个分支事务执行js失败,则通知所有已提交的分支事务回滚,恢复 undo_log 记录的数据。

    三,Seata 的四种事务模式

    1. AT 模式(自动事务模式)

    AT(Auto Transaction)模式是 Seata 中最常用的分布式事务模式,适用于对数据库执行常规的 CRUD(增、删、改、查)操作的场景,尤其是简单的 SQL 操作。

    特点

    • 自动化:AT 模式在数据库的每个操作上都自动代理,开发者无需显式地编写事务的提交和回滚操作。Seata 会自动插入 undo 日志,在事务回滚时自动恢复数据库的原始状态。
    • 无须业务代码改动:AT 模式的关键优势是,开发者无需修改现有的业务代码。通过 Seata 自动管理事务,开发者只需确保数据库支持 undo 日志(例如 mysql、oracle 等)。
    • 仅适用于数据库操作:AT 模式适用于标准的数据库操作,它依赖于数据库的日志和 undo 日志机制。

    工作原理

    • Try 阶段:Seata 会拦截数据库的更新操作,并记录 undo 日志,但不立即提交。此时,数据库的数据并未真正修改,而是保留了“回滚”的信息。
    • Commit 阶段:当全局事务提交时,Seata 会通过协调所有分支事务,最终确认提交所有的数据修改。
    • Rollback 阶段:如果全局事务失败,则会通过回滚所有分支事务的操作,恢复数据。

    适用场景

    • 适用于大多数微服务场景,尤其是直接依赖数据库操作的业务逻辑,Seata 会自动进行事务控制。

    2. TCC 模式(Try-Confirm-Cancel)

    TCC(Try-Confirm-Cancel)模式是一种基于补偿的分布式事务模式,它适用于业务操作较为复杂、涉及多个服务的场景。与 AT 模式的自动提交和回滚不同,TCC 模式要求开发者显式地实现 TryConfirmCancel 这三个阶段。

    特点

    • 精确控制:开发者需要编写 Try、Confirm 和 Cancel 方法,能够精确控制每个阶段的事务操作。
    • 高灵活性:TCC 模式适用于复杂的业务操作,尤其是那些需要进行资源锁定、状态更新、外部系统调用的场景。
    • 手动补偿:TCC 模式的关键是补偿机制,若某个操作失败,需要通过 Cancel 操作来撤销之前的资源占用或状态变更。

    工作原理

    • Try 阶段:执行实际的业务python操作,但不会提交(例如,锁定资源、预扣资金)。此时,操作是幂等的,并且不改变系统状态。
    • Confirm 阶段:如果 Try 阶段成功,Confirm 阶段会提交操作,确认业务操作完成(例如,实际扣款、最终更新库存)。
    • Cancel 阶段:如果 Try 阶段失败或某个分支事务失败,则执行 Cancel 操作,撤销之前的操作(例如,解锁资源、退款)。

    适用场景

    • 长时间执行的业务:例如支付、库存扣减等复杂的跨服务操作,需要实现显式的补偿机制。
    • 必须确保操作的最终一致性:TCC 能够处理在服务之间的协作,并确保每个服务能明确知道何时提交或回滚事务。

    3. SAGA 模式

    SAGA(长事务模式)是一个分布式事务处理模式,适用于跨多个微服务的长事务。与 TCC 模式不同,SAGA 模式通过将长事务拆分成多个小事务来保证一致性,每个小事务都会有一个补偿事务(Compensating Transaction),用于回滚操作。

    特点

    • 长事务拆分:将大事务拆分为一系列小事务,每个小事务都可以独立提交或回滚。
    • 补偿机制:每个小事务都需要实现一个补偿事务,当某个事务失败时,通过补偿事务来撤销之前的操作。
    • 可以异步执行:每个子事务之间可以独立执行,并且可以异步执行,不需要像 TCC 那样锁定资源。

    工作原理

    • 子事务:将全局事务拆分为多个子事务,每个子事务执行独立的操作(例如,支付、库存扣减等)。
    • 补偿操作:每个子事务都有相应的补偿操作。如果某个子事务失败,执行补偿操作撤销之前的操作。
    • 全局事务结束:当所有子事务都执行成功时,结束整个 SAGA 事务;如果某个子事务失败,则根据补偿规则进行回滚。

    适用场景

    • 长时间的、跨多个服务的事务:例如订单的创建、支付、发货等操作。
    • 能够容忍部分失败的场景:SAGA 模式适用于业务流程中的某些操作失败后,可以通过补偿机制修复的场景。

    4. XA 模式(原生分布式事务)

    XA 模式是传统的分布式事务协议,它基于 XA协议,是一种强一致性的分布式事务模式。Seata 的 XA 模式要求参与者支持 XA 事务协议,例如数据库、消息队列等。

    特点

    • 强一致性:XA 模式是最严格的分布式事务协议,确保所有分布式事务的最终一致性。
    • 两阶段提交协议(2PC):与 AT 模式类似,XA 模式也采用了 2PC 协议来管理事务一致性。
    • 依赖于底层数据库的支持:必须使用支持 XA 事务的数据库(例如,MySQL、Oracle 等)。

    工作原理

    • 第一阶段(Prepare):所有参与者准备提交事务,但不提交。
    • 第二阶段(Commit/Rollback):如果所有参与者都准备好,则提交事务,否则回滚事务。

    适用场景

    • 严格要求强一致性的场景:例如银行转账等对事务一致性要求极高的业务。

    总结

    Seata 支持以下四种分布式事务模式:

    1. AT 模式:适用于标准的数据库操作,自动管理事务,适合不涉及复杂业务逻辑的场景。
    2. TCC 模式:适用于跨多个服务的复杂业务,需要手动编写补偿逻辑。
    3. SAGA MZegnBsXM模式:适用于长事务,适合拆分为多个子事务的场景,每个子事务都可以独立回滚。
    4. XA 模式:严格一致性的分布式事务协议,适用于需要强一致性的场景,如金融交易等。

    以上为个人经验,希望能给大家一个参考,也希望大家多多支持编程客栈(www.devze.com)。

    0

    精彩评论

    暂无评论...
    验证码 换一张
    取 消

    关注公众号