分布式事务

事务具有四大特性：

在微服务项目中，每个服务都有其自己的数据库，当我们需要进行服务调用处理业务时，事务还能保证ACID原则吗？我们以一个分布式服务案例来验证这个问题：

案例：微服务下单业务，在下单时会调用订单服务，创建订单并写入数据库。然后订单服务调用账户服务和库存服务

• 账户服务负责扣减用户余额
• 库存服务负责扣减商品库存

Ⅰ.创建数据库heima，里面有三张表，分别对应三种服务要使用到的数据。

订单服务：

账户服务：

库存服务：

Ⅱ. 导入项目seata-demo

① account-service（port：8083）

AccountServiceImpl：

@Slf4j
@Service
public class AccountServiceImpl implements AccountService {

    @Autowired
    private AccountMapper accountMapper;

    @Override
    @Transactional
    public void deduct(String userId, int money) {
        log.info("开始扣款");
        try {
            accountMapper.deduct(userId, money);
        } catch (Exception e) {
            throw new RuntimeException("扣款失败，可能是余额不足！", e);
        }
        log.info("扣款成功");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

AccountController：

@RestController
@RequestMapping("account")
public class AccountController {

    @Autowired
    private AccountService accountService;

    @PutMapping("/{userId}/{money}")
    public ResponseEntity<Void> deduct(@PathVariable("userId") String userId, @PathVariable("money") Integer money){
        accountService.deduct(userId, money);
        return ResponseEntity.noContent().build();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

② order-service（port：8082）

OrderServiceImpl：

@Slf4j
@Service
public class OrderServiceImpl implements OrderService {

    private final AccountClient accountClient;
    private final StorageClient storageClient;
    private final OrderMapper orderMapper;

    public OrderServiceImpl(AccountClient accountClient, StorageClient storageClient, OrderMapper orderMapper) {
        this.accountClient = accountClient;
        this.storageClient = storageClient;
        this.orderMapper = orderMapper;
    }

    @Override
    @Transactional
    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();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

OrderController：

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

    private final OrderService orderService;

    public OrderController(OrderService orderService) {
        this.orderService = orderService;
    }

    @PostMapping
    public ResponseEntity<Long> createOrder(Order order){
        Long orderId = orderService.create(order);
        return ResponseEntity.status(HttpStatus.CREATED).body(orderId);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

③storage-service

StorageServiceImpl：

@Slf4j
@Service
public class StorageServiceImpl implements StorageService {

    @Autowired
    private StorageMapper storageMapper;

    @Transactional
    @Override
    public void deduct(String commodityCode, int count) {
        log.info("开始扣减库存");
        try {
            storageMapper.deduct(commodityCode, count);
        } catch (Exception e) {
            throw new RuntimeException("扣减库存失败，可能是库存不足！", e);
        }
        log.info("扣减库存成功");
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

StorageController：

@RestController
@RequestMapping("storage")
public class StorageController {

    private final StorageService storageService;

    public StorageController(StorageService storageService) {
        this.storageService = storageService;
    }

    /**
     * 扣减库存
     * @param code 商品编号
     * @param count 要扣减的数量
     * @return 无
     */
    @PutMapping("/{code}/{count}")
    public ResponseEntity<Void> deduct(@PathVariable("code") String code,@PathVariable("count") Integer count){
        storageService.deduct(code, count);
        return ResponseEntity.noContent().build();
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

Ⅲ. 测试，发送Post请求

正常的业务我们是可以处理的。我们现在创建一个新的订单，购买10件商品（目前库存只有8件），看看事务是否能回滚。

这里500报错，我们查看数据库数据是否发生了改变：

可以看到，订单表并未添加新的数据且库存表中的库存仍然为8，但我们的账户表中的金额扣了！这显然是不对的。

在分布式系统下，一个业务跨越多个服务或数据源，每个服务都是一个分支事务，要保证所有分支事务最终状态一致，这样的事务就是分布式事务。

而在上例中，各分支事务各自提交各自的，当库存不足导致业务失败时，账户服务并未回滚，导致状态无法一致。那么如何解决分布式事务的问题呢？

理论基础

CAP定理

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

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

Eric Brewer说，分布式系统无法同时满足这三个指标。这个结论就叫做CAP定理。

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

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

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

分布式系统节点通过网络连接，一定会出现分区问题，而分区出现时，系统的可用性和一致性就无法同时得到满足。

注：前面章节搭建的Elasticsearch集群采用的是高一致性且低可用性的CP方案

BASE理论

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

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

而分布式事务最大的问题就是各个子事务的一致性问题，因此可用借鉴CAP定理和BASE理论：

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

解决分布式事务，各个子系统之间必须能感知到彼此的事务状态，才能保证状态一致，因此需要一个事务协调者来协调每一个事务的参与者（子系统事务）。

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

初识Seata

Seata的架构

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

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

Seata提供了四种不同的分布式事务解决方案：

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

部署TC服务

首先我们要下载seata-server包，地址在http://seata.io/zh-cn/blog/download.html。

下载好后解压到非中文目录。

修改conf下的registry.conf文件

registry {
  # tc服务的注册中心类，这里选择nacos，也可以是eureka、zookeeper等
  type = "nacos"

  nacos {
    # seata tc 服务注册到 nacos的服务名称，可以自定义
    application = "seata-tc-server"
    serverAddr = "127.0.0.1:8848"
    group = "DEFAULT_GROUP"
    namespace = ""
    cluster = "SH"
    username = "nacos"
    password = "nacos"
  }
}

config {
  # 读取tc服务端的配置文件的方式，这里是从nacos配置中心读取，这样如果tc是集群，可以共享配置
  type = "nacos"
  # 配置nacos地址等信息
  nacos {
    serverAddr = "127.0.0.1:8848"
    namespace = ""
    group = "SEATA_GROUP"
    username = "nacos"
    password = "nacos"
    dataId = "seataServer.properties"
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

在nacos中添加配置

让tc服务的集群可以共享配置，选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。

# 数据存储方式，db代表数据库
store.mode=db
store.db.datasource=druid
store.db.dbType=mysql
store.db.driverClassName=com.mysql.cj.jdbc.Driver
store.db.url=jdbc:mysql://127.0.0.1:3306/seata?useUnicode=true&rewriteBatchedStatements=true&serverTimezone=Asia/Shanghai
store.db.user=root
store.db.password=123456
store.db.minConn=5
store.db.maxConn=30
store.db.globalTable=global_table
store.db.branchTable=branch_table
store.db.queryLimit=100
store.db.lockTable=lock_table
store.db.maxWait=5000
# 事务、日志等配置
server.recovery.committingRetryPeriod=1000
server.recovery.asynCommittingRetryPeriod=1000
server.recovery.rollbackingRetryPeriod=1000
server.recovery.timeoutRetryPeriod=1000
server.maxCommitRetryTimeout=-1
server.maxRollbackRetryTimeout=-1
server.rollbackRetryTimeoutUnlockEnable=false
server.undo.logSaveDays=7
server.undo.logDeletePeriod=86400000

# 客户端与服务端传输方式
transport.serialization=seata
transport.compressor=none
# 关闭metrics功能，提高性能
metrics.enabled=false
metrics.registryType=compact
metrics.exporterList=prometheus
metrics.exporterPrometheusPort=9898
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

创建数据库表

创建数据库seata，配置如下：

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

-- ----------------------------
-- 分支事务表
-- ----------------------------
DROP TABLE IF EXISTS `branch_table`;
CREATE TABLE `branch_table`  (
  `branch_id` bigint(20) NOT NULL,
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `resource_group_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `branch_type` varchar(8) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `status` tinyint(4) NULL DEFAULT NULL,
  `client_id` varchar(64) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime(6) NULL DEFAULT NULL,
  `gmt_modified` datetime(6) NULL DEFAULT NULL,
  PRIMARY KEY (`branch_id`) USING BTREE,
  INDEX `idx_xid`(`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

-- ----------------------------
-- 全局事务表
-- ----------------------------
DROP TABLE IF EXISTS `global_table`;
CREATE TABLE `global_table`  (
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `status` tinyint(4) NOT NULL,
  `application_id` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_service_group` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `transaction_name` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `timeout` int(11) NULL DEFAULT NULL,
  `begin_time` bigint(20) NULL DEFAULT NULL,
  `application_data` varchar(2000) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`xid`) USING BTREE,
  INDEX `idx_gmt_modified_status`(`gmt_modified`, `status`) USING BTREE,
  INDEX `idx_transaction_id`(`transaction_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;

SET FOREIGN_KEY_CHECKS = 1;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

启动tc服务

进入到seata文件夹下的bin目录，运行seata-server.bat即可。

启动成功后，就可以在nacos的服务列表中看到了：

微服务集成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>
        <!--seata starter 采用1.4.2版本-->
        <dependency>
            <groupId>io.seata</groupId>
            <artifactId>seata-spring-boot-starter</artifactId>
            <version>${seata.version}</version>
        </dependency>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

步骤二：配置application.yml，让微服务通过注册中心找到seata-tc-server

seata:
  registry: # TC服务注册中心的配置，微服务根据这些信息去注册中心获取tc服务地址
    # 参考tc服务自己的registry.conf中的配置
    type: nacos
    nacos: # tc
      server-addr: 127.0.0.1:8848
      namespace: ""
      group: DEFAULT_GROUP
      application: seata-tc-server # tc服务在nacos中的服务名称
      username: nacos
      password: nacos
  tx-service-group: seata-demo # 事务组，根据这个获取tc服务的cluster名称
  service:
    vgroup-mapping: # 事务组与TC服务cluster的映射关系
      seata-demo: LZ
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

在案例中的三个服务上都集成Seata，并重启服务。

实践

XA模式

XA模式原理

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

Seata的XA模式

seata的XA模式做了一些调整，但大体相似：

RM一阶段的工作

1. 注册分支事务到TC
2. 执行分支业务sql但不提交
3. 报告执行状态到TC

TC二阶段的工作：

• TC检测各分支事务执行状态
  • 如果都成功，通知所有RM提交事务
  • 如果都失败，通知所有RM回滚事务

RM二阶段的工作：

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

XA模式的优缺点

优点：

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

缺点：

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

实现XA模式

Seata的starter已经完成了XA模式的自动装配，步骤如下：

Ⅰ.修改application.yml（每个参与事务的微服务），开启XA模式

seata:
  data-source-proxy-mode: XA
1
2

Ⅱ. 给发起全局事务的入口方法添加@GlobalTransaction注解，此处是order-service中的OrderServiceImpl类的create方法。

    @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();
    }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Ⅲ.重启服务并测试

注：这里使用jdbc驱动8.0.28版本500报错，换为8.0.11且加入时区后成功执行。

AT模式

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

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

阶段二提交时RM的工作：

• 删除undo-log

阶段二回滚时RM的工作：

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

例如，一个分支业务的SQL是update tb_account set money = money - 10 where id = 1

AT模式的脏写问题

当事务1获取DB锁后，执行完业务sql并提交后，释放了DB锁。（此时money为90）

此时事务2获取DB锁，执行完业务sql并提交后，释放了DB锁。（此时money为80）

此时事务1获取了DB锁，在阶段2时根据快照恢复数据，将money恢复至100，数据就出现了问题。

针对这个问题，AT模式采用了全局锁的方式来解决。

AT模式的写隔离

全局锁由TC记录当前正在操作的某行数据的事务，此时只有该事务持有全局锁，其他事务不能对这行数据进行写操作。

当事务1获取DB锁，保存快照，执行业务sql后尝试获取全局锁，此时TC记录了这条数据由事务1具备执行权。紧接着提交事务，释放DB锁。（money值为90）

当事务2获取DB锁，保存快照，执行业务sql后尝试获取全局锁，由于TC已记录了事务1具备该数据的执行权，因此拒绝给事务2全局锁。为了事务2一直获取全局锁而导致死锁，加入了重试机制，默认30次，间隔10ms。当超时后回滚数据并释放DB锁。

紧接着事务1获取DB锁，根据快照恢复数据后释放全局锁。数据也正确的进行了回滚。

特殊情况：另一个事务不集成seata对数据进行修改

在这种情况下，保存两个快照，一个是修改前的快照，一个是修改后的快照。

当要进行回滚时会对当前数据的状态和修改后的快照的数据状态进行比对，若一致则回滚到修改前的快照；若不一致则记录异常，发送警告进行人工介入。

总结：AT模式的优缺点

优点：

• 一阶段完成直接提交事务，释放数据库资源，性能比较好。
• 利用全局锁实现读写隔离。
• 没有代码侵入，框架自动完成回滚和提交。

缺点：

• 两阶段之间属于软状态，属于最终一致。
• 框架的快照功能会影响性能，但比XA模式要好很多。

实现AT模式

Ⅰ.创建两张表，lock_table导入到TC服务关联的数据库，undo_log表导入到微服务关联的数据库。

lock_table：

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,
  `transaction_id` bigint(20) NULL DEFAULT NULL,
  `branch_id` bigint(20) NOT NULL,
  `resource_id` varchar(256) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `table_name` varchar(32) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `pk` varchar(36) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `gmt_create` datetime NULL DEFAULT NULL,
  `gmt_modified` datetime NULL DEFAULT NULL,
  PRIMARY KEY (`row_key`) USING BTREE,
  INDEX `idx_branch_id`(`branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = Compact;
1
2
3
4
5
6
7
8
9
10
11
12
13
14

undo_log：

DROP TABLE IF EXISTS `undo_log`;
CREATE TABLE `undo_log`  (
  `branch_id` bigint(20) NOT NULL COMMENT 'branch transaction id',
  `xid` varchar(100) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'global transaction id',
  `context` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL COMMENT 'undo_log context,such as serialization',
  `rollback_info` longblob NOT NULL COMMENT 'rollback info',
  `log_status` int(11) NOT NULL COMMENT '0:normal status,1:defense status',
  `log_created` datetime(6) NOT NULL COMMENT 'create datetime',
  `log_modified` datetime(6) NOT NULL COMMENT 'modify datetime',
  UNIQUE INDEX `ux_undo_log`(`xid`, `branch_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci COMMENT = 'AT transaction mode undo table' ROW_FORMAT = Compact;
1
2
3
4
5
6
7
8
9
10
11

Ⅱ.修改yml文件，将事务模式修改为AT即可

seata:
  data-source-proxy-mode: AT
1
2

Ⅲ.重启服务并测试

TCC模式

TCC模式与AT模式非常相似，每个阶段都是独立的事务，不同的是TCC通过人工编码来实现数据恢复，需要实现三个方法：

• Try：资源的检测和预留
• Confirm：完成资源操作业务，要求Try成功Confirm一定要能成功。
• Cancel：预留资源释放，可理解为try的反向操作。

TCC模式原理

TCC的优越点

优点：

• 一阶段完成直接提交事务，释放数据库资源，性能好。
• 相比AT模型，无需生成快照，无需使用全局锁，性能最强。
• 不依赖数据库事务，而是依赖补偿操作，可以用于非事务型数据库。

缺点：

• 有代码侵入，需要人为编写try、Confirm和Cancel接口，过于麻烦。
• 软状态，事务最终一致。
• 需要考虑Confirm和Cancel的失败情况，需要做好幂等处理。

案例：改造account-service服务，利用TCC实现分布式事务

需求如下：

• 修改account-service，编写try、confirm、cancel逻辑。
• try业务：添加冻结金额，扣减可用金额。
• confirm业务：删除冻结金额。
• cancel业务：删除冻结金额，恢复可用金额。
• 保证confirm、cancel业务的幂等性。
• 允许空回滚。
• 拒绝业务悬挂。

TCC的空回滚和业务悬挂：

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

对于已经空回滚的业务，如果以后继续执行try，就永远不可能confirm或cancel，这就是业务悬挂。应当阻止执行空回滚后的try操作，避免悬挂。

业务分析

DROP TABLE IF EXISTS `account_freeze_tbl`;
CREATE TABLE `account_freeze_tbl`  (
  `xid` varchar(128) CHARACTER SET utf8 COLLATE utf8_general_ci NOT NULL,
  `user_id` varchar(255) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL,
  `freeze_money` int(11) UNSIGNED NULL DEFAULT 0,
  `state` int(1) NULL DEFAULT NULL COMMENT '事务状态，0:try，1:confirm，2:cancel',
  PRIMARY KEY (`xid`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8 COLLATE = utf8_general_ci ROW_FORMAT = COMPACT;
1
2
3
4
5
6
7
8

声明TCC接口

TCC的Try、Confirm、Cancel方法都需要在接口中基于注解声明，语法如下：

@LocalTCC
public interface AccountTCCService {
	/**
	* Try逻辑，@TwoPhaseBusinessAction中的name属性名要与当前方法名一致，用于指定try逻辑对应的方法
	*/
    @TwoPhaseBusinessAction(name = "deduct", commitMethod = "confirm", rollbackMethod = "cancel")
    void deduct(@BusinessActionContextParameter(paramName = "userId") String userId,
                @BusinessActionContextParameter(paramName = "money") int money);
	

    /**
     * 二阶段confirm确认方法，可以另命名，但要保证与commitMethod一致
     * @param ctx 上下文，可以传递try方法的参数
     * @return 执行是否成功
     */
    boolean confirm(BusinessActionContext ctx);

    /**
     * 二阶段回滚方法，要保证与rollbackMethod一致
     * @param ctx 
     * @return
     */
    boolean cancel(BusinessActionContext ctx);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

SAGA模式

SAGA模式是Seata提供的长事务解决方案，分为两个阶段：

• 一阶段：直接提交本地事务
• 二阶段：成功则什么都不做，失败则通过编写补偿业务来回滚。

SAGA模式优点：

• 事务参与者可以基于事件驱动实现异步调用，吞吐高。
• 一阶段直接提交事务，无锁，性能好。
• 不用编写TCC中的三个阶段，实现简单。

缺点：

• 软状态持续时间不确定，时效性差
• 没有锁，没有事务隔离，会导致脏写

比较适用于跨银行转账的长事务等。

四种模式对比