Seata 的事务补偿机制:如何保证业务最终一致性?

云计算 分布式
通过本篇文章,我们详细探讨了 Seata 的事务补偿机制如何保证分布式事务的最终一致性,并结合 Spring Boot 和 Spring Cloud 框架,给出了具体的代码示例。希望这篇文章能帮助你更好地理解 Seata 在分布式事务中的应用,保障业务的高可用和数据的一致性。

在分布式系统中,多个服务可能需要协同工作来完成一个业务操作。为了确保每个服务都能正确地执行任务,分布式事务就变得至关重要。Seata 作为一个高性能的分布式事务解决方案,提供了事务补偿机制来保证分布式事务的最终一致性。

在这篇文章中,我们将深入探讨 Seata 如何使用事务补偿机制来保证分布式事务的最终一致性,详细讲解 Seata 中的补偿原理和实现方式,并通过一个实际的 Spring Boot 和 Spring Cloud 整合示例,展示如何在 Seata 中处理事务失败后的补偿操作。

1. Seata 的事务补偿机制概述

1.1 什么是事务补偿?

事务补偿(Compensation)是指在分布式事务中,当某个服务执行失败时,通过执行补偿操作来保证数据的最终一致性。补偿操作并非撤销操作,而是通过一组特定的操作来撤销之前的操作或恢复到一种一致性状态。例如,如果用户预定了一个商品,而支付失败,我们可以通过补偿操作来释放锁定的库存或回滚预定操作。

1.2 Seata 中的事务补偿

Seata 中的分布式事务保证机制分为两种模式:TCC(Try Confirm Cancel)*和*SAGA。这两种模式各自通过不同的补偿机制来保证事务的一致性。

  • TCC(Try Confirm Cancel)模式:TCC 是一种两阶段的事务模型,首先通过 Try 阶段进行资源预留,然后通过 Confirm 阶段完成实际操作,最后如果出现异常则通过 Cancel 阶段进行补偿,撤销之前的操作。
  • SAGA 模式:SAGA 模式是通过一组局部事务来实现分布式事务的补偿,每个局部事务都拥有自己的补偿操作。当某个局部事务失败时,其他局部事务将按照预定的补偿逻辑进行回滚。

在 Seata 中,TCC 模式通过三阶段的提交(Try、Confirm、Cancel)来保证最终一致性,而 SAGA 模式则通过定义补偿事务来进行事务的回滚和补偿。

1.3 事务补偿的实现原理

Seata 的事务补偿机制基于两大核心原理:

  • 事务日志记录:Seata 会记录事务的执行日志,包括每个分支事务的状态。这些日志会帮助补偿操作恢复事务的状态。
  • 补偿回滚:当事务的某个分支失败时,Seata 会通过回滚操作触发其他分支事务的补偿操作,确保数据的最终一致性。

2. Seata 的补偿机制实现

2.1 补偿机制的配置与整合

为了更好地理解 Seata 的补偿机制,我们可以通过 Spring Boot 和 Spring Cloud 来集成 Seata,并进行补偿机制的配置。

2.1.1 Spring Boot 集成 Seata

首先,我们需要在 Spring Boot 项目中引入 Seata 的依赖。

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>1.5.2</version>
</dependency>

然后,在 application.yml 配置文件中进行 Seata 的配置。

seata:
  tx-service-group: my_test_tx_group # 定义事务服务组
  service:
    vgroup-mapping:
      my_test_tx_group: default # 配置事务组映射
  store:
    mode: db # 使用数据库存储事务日志
    db:
      datasource:
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://localhost:3306/seata
        username: root
        password: root

2.1.2 Spring Cloud 集成 Seata

Spring Cloud 集成 Seata 主要依赖于 Seata 提供的 Spring Cloud 配置。这些配置项与 Spring Boot 项目类似,唯一不同的是需要添加 seata-spring-cloud-starter 依赖。

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-cloud-starter</artifactId>
    <version>1.5.2</version>
</dependency>

配置 application.yml 文件,配置 Seata 的服务信息。

seata:
  tx-service-group: my_test_tx_group
  service:
    vgroup-mapping:
      my_test_tx_group: default
  store:
    mode: db
    db:
      datasource:
        driver-class-name: com.mysql.cj.jdbc.Driver
        url: jdbc:mysql://localhost:3306/seata
        username: root
        password: root

2.1.3 Seata 配置数据库表

Seata 需要创建一些数据库表来存储事务信息,确保事务的执行状态能够持久化。可以通过以下 SQL 创建 Seata 所需的表:

CREATE TABLE `undo_log` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(128) NOT NULL,
  `context` varchar(128) NOT NULL,
  `rollback_info` blob,
  `log_status` int(11) NOT NULL,
  `log_created` datetime NOT NULL,
  `log_updated` datetime NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `UK_XID_BRANCH_ID` (`xid`, `branch_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

2.2 TCC 模式实现

在 Seata 中,TCC 模式是保证事务补偿的一种重要方式。TCC 模式包括三个操作:TryConfirm 和 Cancel。以下是一个实际的 TCC 示例。

2.2.1 订单服务(Order Service)

首先,定义一个 TCC 订单服务接口:

public interface OrderService {
    void createOrder(Order order);
    void cancelOrder(Long orderId);
    void confirmOrder(Long orderId);
}

实现类 OrderServiceImpl,包括 tryconfirm 和 cancel 操作。

@Service
public class OrderServiceImpl implements OrderService {

    @Resource
    private OrderRepository orderRepository;
    @Resource
    private ProductService productService;
    
    @Override
    @Transactional
    public void createOrder(Order order) {
        // 1. 执行 Try 操作,预留库存
        productService.reserveStock(order.getProductId(), order.getQuantity());
        orderRepository.save(order);
    }

    @Override
    @Transactional
    public void cancelOrder(Long orderId) {
        // 2. 执行 Cancel 操作,回滚库存
        Order order = orderRepository.findById(orderId).orElseThrow(() -> new RuntimeException("Order not found"));
        productService.releaseStock(order.getProductId(), order.getQuantity());
        orderRepository.delete(order);
    }

    @Override
    @Transactional
    public void confirmOrder(Long orderId) {
        // 3. 执行 Confirm 操作,完成订单
        Order order = orderRepository.findById(orderId).orElseThrow(() -> new RuntimeException("Order not found"));
        order.setStatus(OrderStatus.COMPLETED);
        orderRepository.save(order);
    }
}

2.2.2 订单控制器

创建一个控制器来处理前端请求。

@RestController
@RequestMapping("/order")
public class OrderController {

    @Resource
    private OrderService orderService;
    
    @PostMapping("/create")
    public ResponseEntity<String> createOrder(@RequestBody Order order) {
        orderService.createOrder(order);
        return ResponseEntity.ok("Order created successfully");
    }

    @PostMapping("/cancel/{orderId}")
    public ResponseEntity<String> cancelOrder(@PathVariable Long orderId) {
        orderService.cancelOrder(orderId);
        return ResponseEntity.ok("Order canceled successfully");
    }

    @PostMapping("/confirm/{orderId}")
    public ResponseEntity<String> confirmOrder(@PathVariable Long orderId) {
        orderService.confirmOrder(orderId);
        return ResponseEntity.ok("Order confirmed successfully");
    }
}

2.2.3 配置 TCC 事务管理器

在 Spring Boot 中启用 Seata 的 TCC 模式,需要配置 Seata 事务管理器。

seata:
  tcc:
    enable: true

3. 补偿机制总结

通过 Seata 提供的事务补偿机制,我们能够在分布式事务中,确保数据的一致性。无论是通过 TCC 还是 SAGA 模式,Seata 都能够在事务执行失败时,通过补偿操作恢复事务的状态,保证最终一致性。

3.1 补偿的核心操作

Seata 的补偿机制包含两大核心操作:

  • Try 操作:资源预留阶段,尝试进行资源操作。
  • **Cancel 操作

**:如果 Try 操作失败,则执行补偿,撤销之前的资源预留。

  • Confirm 操作:当业务操作成功时,执行确认操作。

3.2 配置和整合

Seata 通过 Spring Boot 和 Spring Cloud 提供了强大的整合支持,使得分布式事务的补偿机制配置简单而灵活。通过简单的配置,我们可以实现分布式系统的事务一致性和补偿回滚操作。

总结

通过本篇文章,我们详细探讨了 Seata 的事务补偿机制如何保证分布式事务的最终一致性,并结合 Spring Boot 和 Spring Cloud 框架,给出了具体的代码示例。希望这篇文章能帮助你更好地理解 Seata 在分布式事务中的应用,保障业务的高可用和数据的一致性。

责任编辑:武晓燕 来源: 架构师秋天
相关推荐

2021-03-04 06:49:53

RocketMQ事务

2021-07-21 15:50:42

Serverless 业务部署

2022-10-19 12:22:53

并发扣款一致性

2023-10-08 08:29:31

2021-07-26 06:33:42

CRDT数据CAP

2019-08-30 12:46:10

并发扣款查询SQL

2020-08-05 08:46:10

NFS网络文件系统

2024-01-10 08:01:55

高并发场景悲观锁

2024-12-26 15:01:29

2021-06-16 08:33:02

分布式事务ACID

2023-09-07 08:11:24

Redis管道机制

2020-01-02 09:06:23

微服务数据框架

2021-12-01 08:26:27

数据库缓存技术

2021-06-22 10:22:08

业务IT一致性首席信息官

2020-04-01 15:50:17

TiDBMySQL数据库

2020-06-01 22:09:48

缓存缓存同步缓存误用

2023-07-25 09:52:00

本地事务宕机

2021-12-14 07:15:57

MySQLRedis数据

2024-12-11 09:16:38

2023-05-26 07:34:50

RedisMySQL缓存
点赞
收藏

51CTO技术栈公众号