Seata分布式事務框架原理詳解

一、Seata原理詳解

Seata 是一個高性能、易用的分布式事務解決方案，提供了 AT/ TCC/ Saga 三種分布式事務模式，並支持 Spring、Dubbo 以及 Node.js 等多種技術棧。它提供了全局唯一的事務 ID，以及基於本地多階段提交協議、全局鎖的機制來實現分布式事務的一致性。

Seata 的整體分為 TC、RM、TM 三個部分：

TC（Transaction Coordinator）: 全局事務協調者，負責全局事務的創建、提交和回滾等。在整個分布式事務中起到重要的協調作用，確保全局事務的一致性和可靠性。

TM（Transaction Manager）: 事務管理器，負責本地事務的操作，包括本地事務的創建、提交和回滾等。與 TC 配合工作，實現分布式事務的管理。

RM（Resource Manager）：資源管理器，負責本地資源的管理，在 Seata 中就是數據庫。RM 因為修改了數據，也要保證分布式事務的一致性。

二、Seata原理是誰

Seata分布式事務框架是阿里巴巴集團於2019年推出的一個開源分布式事務框架，由鳥哥（余國躍）帶領的阿里雲中間件事業部孵化開發。鳥哥是阿里雲中間件事業部資深技術專家，涉及阿里雲分布式存儲、消息隊列、分布式事務等多個領域。

三、Seata原理案例

下面是 Seata 官方提供的一個訂單表與庫存表的分布式事務案例：

// 訂單服務接口
public interface OrderService {
    public boolean createOrder(Order order);
}

// 訂單表
create table order(
    id int auto_increment primary key,
    user_id int not null,
    product_id int not null,
    product_count int not null,
    add_time datetime not null,
    update_time datetime not null
);

// 庫存服務接口
public interface ProductService {
    public boolean reduceStock(Product product);
}

// 庫存表
create table product(
    id int auto_increment primary key,
    product_id int not null,
    stock_count int not null,
    add_time datetime not null,
    update_time datetime not null
);

在這個分布式事務案例中，訂單服務需要調用庫存服務，當訂單服務創建訂單成功後，需要更新庫存表，減少對應商品的庫存。這個過程中，如果有任何一個服務出現異常，就需要回滾之前的所有操作，保證數據的一致性。

四、Seata原理TCC和AT

Seata 支持 AT 和 TCC 兩種分布式事務模式。

1. Seata TCC 模式

Seata TCC（Try-Confirm-Cancel）模式，一般用於業務流程比較複雜、需要參與者自己編寫業務邏輯的場景。在 TCC 中，參與者需要自己實現 Try、Confirm、Cancel 三個階段的業務邏輯。

Try 階段通常是在主業務中創建一個唯一標示的分布式事務，並記錄 TCC 方法的執行順序與回滾操作信息；Confirm 階段通常是在主業務提交成功後執行，以確認各參與者執行結果，如果出現異常則需要回滾操作；Cancel 階段通常是在超時、或回滾業務後執行，以釋放資源和鎖。

2. Seata AT 模式

Seata AT（Automatic Transaction）模式，又稱作 XA 模式，與 TCC 模式相比，AT 更加簡單，不需要程序員手動實現 Try、Confirm、Cancel 三個階段的業務邏輯。AT 模式採用了全局公共鎖來保證各分支事務的一致性和可靠性。

五、Seata AT原理

Seata AT 模式，是採用了 XA （eXtended Architecture）的技術實現的分布式事務。

XA 是一個分布式事務協議和接口規範，在 Seata 中，XA 起到了很重要的作用，是實現分布式事務的關鍵之一。在 XA 協議下，分布式事務的流程如下：

1. TM（Transaction Manager）創建一個全局唯一的事務 ID，先後通知各個 RM 開啟本地事務；

2. TM 開始全局事務，各 RM 結束本地事務；

3. 各 RM 向 TM 報告本地事務的狀態，TM 根據各 RM 報告的狀態，進行全局事務的提交或回滾。

六、阿里巴巴Seata原理

阿里巴巴 Seata 原理是基於全局唯一的事務 ID 來解決分布式事務一致性和可靠性的。在 Seata 中，TC 為全局唯一的事務 ID 生成器，向 TM 發送分配事務 ID 請求。TM 創建具有全局事務 ID 的本地事務，對 RM 發起分支事務請求，每個 RM 按照分支事務請求創建本地事務，最後，TM 收到 RM 的反饋後，對分布式事務進行提交或回滾操作。

七、Seata框架

Seata 框架整體上是由 TC（Transaction Coordinator）、RM（Resource Manager）、TM（Transaction Manager）和 MSE（Message Sender）四個模塊組成的分布式事務解決方案。在 Seata 中，使用 Java 語言來實現整個分布式事務框架。

八、Seata分布式

Seata 分布式主要是通過對事務進行全局的管理和控制，來確保分布式事務的一致性和可靠性。在分布式應用場景中，不同的節點可能位於不同的地方，而這些節點之前可能會有通信延遲、不可靠的網絡等問題。Seata 分布式主要考慮了這些因素，引入了 Heartbeat 等技術來處理節點通信延遲或故障的問題。

九、Seata 三大模式

1. Seata AT 模式

Seata AT 模式採用了 XA 協議，在分布式事務過程中，Seata AT 通過事務管理器來實現全局事務的管理和控制，從而確保分布式事務的一致性和可靠性。在 AT 模式中，使用全局公共鎖來防止數據被多方操作問題。

2. Seata TCC 模式

Seata TCC 是一種分布式事務模式，相對於 AT 模式，TCC 模式具有更高的可擴展性。與AT模式不同的是，TCC模式下，業務邏輯中 Try、Confirm、Cancel 操作需要業務開發人員自行實現。Try 階段一般用來預留業務數據，Confirm 階段一般用來確認業務數據，而 Cancel 階段一般用來釋放業務資源。

3. Seata SAGA 模式

Seata Saga 模式是一種基於自動補償機制的分布式事務模式。在 Saga 模式下，Seata 主要通過對事務進行狀態記錄，來確保分布式事務的一致性和可靠性。在分布式事務過程中，當一個事務執行失敗時，Seata 就會自動回滾該事務。

十、Seata的幾種模式選取

在使用 Seata 的過程中，開發人員可以根據實際需求，選擇不同的分布式事務模式來實現分布式事務的控制和管理。對於事務較為簡單的情況，可以選擇 Seata AT 模式來處理；對於事務較為複雜的情況，可以選擇 Seata TCC 或 Saga 模式來處理。

代碼示例

1. Seata AT 模式示例

在 Seata AT 模式下，可以通過在 Spring Boot 項目中添加 seata-spring-boot-starter 依賴，來實現分布式事務的控制和管理。

添加依賴

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-all</artifactId>
    <version>1.4.0</version>
</dependency>
<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2.2.1.RELEASE</version>
</dependency>

配置文件

# DataSource
spring.datasource.url = jdbc:mysql://localhost:3306/test
spring.datasource.username = root
spring.datasource.password = 123456
spring.datasource.driver-class-name = com.mysql.jdbc.Driver
spring.datasource.type = com.alibaba.druid.pool.DruidDataSource

# SEATA
spring.cloud.alibaba.seata.tx-service-group = seata-tx-group
feign.hystrix.enabled = false

# MyBatis
mybatis.mapper-locations = classpath:mapper/*.xml

mybatis.configuration.map-underscore-to-camel-case=true
mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl

# Spring
spring.application.name=springcloud-storage-service
server.port=8081
eureka.instance.instance-id=${spring.application.name}:${spring.cloud.client.ip-address}:${server.port}
eureka.client.service-url.defaultZone=http://localhost:8761/eureka/

分布式事務管理器

@Data
@Configuration
public class DataSourceProxyConfig {

    @Autowired
    private DataSourceProperties dataSourceProperties;

    @Bean
    public DataSource dataSource() {

        DruidDataSource datasource = new DruidDataSource();
        datasource.setUrl(dataSourceProperties.getUrl());
        datasource.setUsername(dataSourceProperties.getUsername());
        datasource.setPassword(dataSourceProperties.getPassword());
        datasource.setDriverClassName(dataSourceProperties.getDriverClassName());

        // spring datasource 監控配置
        datasource.setFilters("stat,wall,log4j");
        datasource.setMaxActive(20);
        datasource.setInitialSize(1);
        datasource.setMaxWait(60000);
        datasource.setMinIdle(1);
        datasource.setValidationQuery("select 'x'");
        datasource.setTestOnBorrow(false);
        datasource.setTestOnReturn(false);
        datasource.setTestWhileIdle(true);
        datasource.setTimeBetweenEvictionRunsMillis(60000);
        datasource.setMinEvictableIdleTimeMillis(25200000);

        try {
            datasource.setFilters("stat");
        } catch (SQLException e) {
            e.printStackTrace();
        }

        return new DataSourceProxy(datasource);
    }
}

2. Seata TCC 模式示例

在 Seata TCC 模式下，需要在業務邏輯中實現 Try、Confirm、Cancel 三個階段的業務邏輯。

接口定義

<pre