✅PmHub 整合 Seata 实现分布式事务

你好，欢迎来到Seata 教程！这篇文章主要讲 PmHub 中如何利用 Seata 分布式事务来保证任务审批状态一致性。

分布式事务是历年来面试最喜欢问的，但我看网上教程都是偏理论的多，联系实际项目的少，而面试最喜欢的是拿着项目拷打。我们的目标是理论联系实际，让你少走弯路~

所以通过本章的学习，让你一次性理解分布式事务，并教你在 PmHub 中如何用好分布式事务，可谓是从道到术，卷起来吧，少年！！

本章可谓是干货满满，面试中也是重中之重，

事务

我们先想象一个场景：

假设用户A向用户B转账100元，这个操作包括以下步骤：

从用户A的账户中扣减100元。

向用户B的账户中增加100元。

这两个步骤要么都成功，要么都失败。如果在步骤1扣减了100元，但步骤2增加时发生了错误，我们希望，用户A的账户金额恢复到原来的状态。

上面是一个典型的事务场景，什么是事务？，简而言之，事务是逻辑上的一组操作，要么都执行，要么都不执行。

下面有一道经典的八股，衡量事务的四大特性的了解程度，理解的背一下就好了。

事务的四大特性（ACID）

原子性（Atomicity）：

事务中的所有操作要么全部成功，要么全部失败。即使在系统故障的情况下，事务也能保证不会只执行一部分操作。

例子：银行转账操作中，从一个账户扣钱并在另一个账户加钱，这两步操作要么都成功，要么都失败。

一致性（Consistency）：

事务执行前后，数据库都必须处于一致的状态。所有事务必须使数据库从一个一致状态变换到另一个一致状态。

例子：转账后，两个账户的总金额应该保持不变。

隔离性（Isolation）：

并发事务之间互不影响，一个事务的中间状态对其他事务不可见。不同事务之间的操作是相互独立的。

例子：同时进行的两个转账操作不会互相干扰，每个操作都看不到对方的中间状态。

持久性（Durability）：

一旦事务提交，其结果是永久性的，即使系统崩溃，事务的结果也不会丢失。

例子：转账成功后，系统崩溃重启，账户金额的变动依然存在

本地事务

在单体应用中的事务其实都属于本地事务，比如在 springboot 中在方法上加 @Transactional 注解，其实走的也是一种本地事务。

在单体中，通常一个操作，可能会涉及多张表，但都位于同一个数据库中，比如在 MySQL 中，一个事务可能包含多条 sql 语句的执行，这些语句要么执行成功，要么都执行失败，MySQL 支持事务的引擎是我们常用的 InnoDB，而 MyISAM 是不支持事务的。

MySQL 中主要是通过 redo log 和 undo log 来控制事务，redo log 是在事务提交前回滚，保证事务的持久性， undo log 是在事务提交后回滚，保证事务的原子性，具体可以看下面这张图：

分布式事务

在分布式微服务系统中，原先的单体系统被拆成了多个微服务，比如 PmHub 中拆分了系统服务，项目服务、流程服务等，在实际应用中，每一个微服务可能会部署在不同的机器上，并且微服务的数据库是隔离的，比如 PmHub 中的 pmhub-project 微服务用的是 pmhub-project 数据库，pmhub-workflow 服务用的是 pmhub-workflow 数据库，

这种情况下，一个操作可能会涉及多个机器、多个服务、多个数据库。比如 PmHub 中的添加项目任务场景。

那么如何保证同一个操作，要么全部执行成功，要么全部执行失败呢？

那就需要用到分布式事务解决方案，本地事务解决的是单数据源的数据一致性问题，分布式事务解决的是多数据源数据一致性问题。

分布式事务解决方案

分布式事务的实现主要有以下 6 种方案：

XA 方案
TCC 方案
SAGA 方案
本地消息表
可靠消息最终一致性方案
最大努力通知方案

其中 XA 方案规范又衍生出了 2PC、3PC 业务代码无侵入方案，TCC 和 SAGA 属于业务侵入方案，本地消息表不支持回滚。

每一种方案都有不同的适用场景，下面一张表是这几种方案的对比：


方案	描述	优点	缺点	适用场景
XA 方案	两阶段提交，通过事务管理器协调多个数据库的事务，适合单块应用里的跨多个库的分布式事务	强一致性	效率低，不适合高并发场景	单块应用，跨多个库的分布式事务
TCC 方案	Try-Confirm-Cancel，通过三个阶段管理事务，Try 阶段检测和预留资源，Confirm 阶段执行操作，Cancel 阶段进行回滚补偿	强一致性，适合短流程、高并发的场景	补偿代码复杂，难以维护	与资金相关的支付、交易等场景
SAGA 方案	补偿事务，通过本地事务和补偿操作保证最终一致性，当一个事务失败时，反向执行已成功的操作进行补偿	无锁，高性能，参与者可异步执行	不保证事务的隔离性	业务流程长、参与者包含其它公司或遗留系统服务的场景
本地消息表	在本地事务中插入消息到消息表，并将消息发送到MQ，接收方在本地事务中处理消息并更新消息状态，如果失败则定时重试	保证最终一致性，适合低并发场景	严重依赖数据库的消息表，高并发场景扩展性差	低并发场景
可靠消息最终一致性方案	基于 MQ 实现事务，先发送预备消息，执行本地事务后确认或回滚消息，MQ 定时检查预备消息状态并回调确认	适合高并发场景，可靠性高	处理复杂，系统 B 的事务失败需要重试或手工处理	高并发场景，目前国内互联网公司多采用
最大努力通知方案	系统 A 执行完本地事务后发送消息到 MQ，最大努力通知服务消费消息并调用系统 B，如果系统 B 执行失败则定时重试，最后失败则放弃	简单易实现，适合对一致性要求不高的场景	不能保证绝对一致性	对一致性要求不高的场景，例如非关键业务操作

Seata 介绍

Seata 是什么

Seata 是一款阿里开源的分布式事务解决方案，是一种简单可扩展自治的事务框架，可以说又是一个国产之光了👍

官网地址：https://seata.apache.org/zh-cn/
开源地址：https://github.com/apache/incubator-seata

有了 Seata，我们只需要在需要使用分布式事务的地方加上 @GlobalTransactional 注解即可。

整体机制

Seata 支持 3 种模式，AT 模式、TCC 模式、Saga 模式


模式	描述	优点	缺点	适用场景
AT 模式	自动补偿事务，通过代理自动管理事务的提交和回滚，适合简单场景	易于使用，开发成本低，自动管理事务	依赖于数据库支持，适合简单场景，不适合复杂业务逻辑	简单的业务场景，如单表操作、小型微服务
TCC 模式	Try-Confirm-Cancel，开发者手动实现业务逻辑的 Try、Confirm 和 Cancel 三个阶段，确保事务的一致性	提供强一致性，适用于需要严格事务管理的场景	实现复杂，开发成本高，需要手动管理事务的各个阶段	对一致性要求高且业务操作较短的场景，如支付、交易等涉及资金的系统
Saga 模式	长事务模式，通过一系列的子事务来完成主事务，子事务之间独立运行，如果某个子事务失败，则通过补偿事务进行回滚	无需全局锁，高性能，适用于长事务场景	需要开发补偿逻辑，可能无法保证强一致性	业务流程长、跨多个系统或服务的场景，如订单管理、供应链管理

AT 模式

AT 模式就是就是 2PC 协议，适用于大部分场景，配置和使用相对也简单，PmHub 中使用到的就是 AT 模式，下面是一个具体的流程：

TCC 模式

所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中。

Saga 模式

Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。

下面就进入 Seata 分布式事务实战环节。

下载安装Seata

下载

下载地址：https://seata.apache.org/zh-cn/unversioned/download/seata-server/

下载最新 2.0.0 版本

建库建表

由于seata使用mysql作为db高可用数据库，故需要在mysql创建一个 pmhub-seata库，并导入数据库脚本。

CREATE DATABASE  `pmhub-seata` DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

SET NAMES utf8mb4;
SET FOREIGN_KEY_CHECKS = 0;

USE `pmhub-seata`;

-- -------------------------------- The script used when storeMode is 'db' --------------------------------
-- the table to store GlobalSession data
CREATE TABLE IF NOT EXISTS `global_table`
(
    `xid`                       VARCHAR...