seata

以下内容，来自 官网

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

seata简介

Seata , 官网 , github , 1万多星

• Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式
• 在 Seata 开源之前，Seata 对应的内部版本在阿里经济体内部一直扮演着分布式一致性中间件的角色，帮助经济体平稳的度过历年的双11，对各BU业务进行了有力的支撑。商业化产品GTS 先后在阿里云、金融云进行售卖

相关链接：

什么是seata：https://seata.io/zh-cn/docs/overview/what-is-seata.html

下载 https://seata.io/zh-cn/blog/download.html
官方例子 https://seata.io/zh-cn/docs/user/quickstart.html

Seata 的三大模块

Seata AT使用了增强型二阶段提交实现。

Seata 分三大模块 :

• TC ：事务协调者。负责我们的事务ID的生成，事务注册、提交、回滚等。
• TM：事务发起者。定义事务的边界，负责告知 TC，分布式事务的开始，提交，回滚。
• RM：资源管理者。管理每个分支事务的资源，每一个 RM 都会作为一个分支事务注册在 TC。

在Seata的AT模式中，TM和RM都作为SDK的一部分和业务服务在一起，我们可以认为是Client。TC是一个独立的服务，通过服务的注册、发现将自己暴露给Client们。

Seata 中有三大模块中， TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。

Seata 的分布式事务的执行流程

在 Seata 中，分布式事务的执行流程：

• TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
• 按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态 ）；
• TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
• TC 汇总事务信息，决定分布式事务是提交还是回滚；
• TC 通知所有 RM 提交/回滚 资源，事务二阶段结束；

Seata的TC、TM、RM三个角色 ， 是不是和XA模型很像. 下图是XA模型的事务大致流程。

在X/Open DTP(Distributed Transaction Process)模型里面，有三个角色：

AP: Application，应用程序。也就是业务层。哪些操作属于一个事务，就是AP定义的。

TM: Transaction Manager，事务管理器。接收AP的事务请求，对全局事务进行管理，管理事务分支状态，协调RM的处理，通知RM哪些操作属于哪些全局事务以及事务分支等等。这个也是整个事务调度模型的核心部分。

RM：Resource Manager，资源管理器。一般是数据库，也可以是其他的资源管理器，如消息队列(如JMS数据源)，文件系统等。

4 种分布式事务解决方案

Seata 会有 4 种分布式事务解决方案，分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。

Seata AT模式

Seata AT模式是最早支持的模式。AT模式是指Automatic (Branch) Transaction Mode自动化分支事务。

Seata AT 模式是增强型2pc模式，或者说是增强型的XA模型。

总体来说，AT 模式，是 2pc两阶段提交协议的演变，不同的地方，Seata AT 模式不会一直锁表。

Seata AT模式的使用前提

• 基于支持本地 ACID 事务的关系型数据库。比如，在MySQL 5.1之前的版本中，默认的搜索引擎是MyISAM，从MySQL 5.5之后的版本中，默认的搜索引擎变更为InnoDB。MyISAM存储引擎的特点是：表级锁、不支持事务和全文索引。 所以，基于MyISAM 的表，就不支持Seata AT模式。
• Java 应用，通过 JDBC 访问数据库。

Seata AT模型图

两阶段提交协议的演变：

• 一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
• 二阶段：

• • 提交异步化，非常快速地完成。
  • 或回滚通过一阶段的回滚日志进行反向补偿

完整的AT在Seata所制定的事务模式下的模型图：

Seata AT模式的例子

我们用一个比较简单的业务场景来描述一下Seata AT模式的工作过程。

有个充值业务，现在有两个服务，一个负责管理用户的余额，另外一个负责管理用户的积分。

当用户充值的时候，首先增加用户账户上的余额，然后增加用户的积分。

Seata AT分为两阶段，主要逻辑全部在第一阶段，第二阶段主要做回滚或日志清理的工作。

第一阶段流程：

第一阶段流程如

1）余额服务中的TM，向TC申请开启一个全局事务，TC会返回一个全局的事务ID。

2）余额服务在执行本地业务之前，RM会先向TC注册分支事务。

3）余额服务依次生成undo log、执行本地事务、生成redo log，最后直接提交本地事务。

4）余额服务的RM向TC汇报，事务状态是成功的。

5）余额服务发起远程调用，把事务ID传给积分服务。

6）积分服务在执行本地业务之前，也会先向TC注册分支事务。

7）积分服务次生成undo log、执行本地事务、生成redo log，最后直接提交本地事务。

8）积分服务的RM向TC汇报，事务状态是成功的。

9）积分服务返回远程调用成功给余额服务。

10）余额服务的TM向TC申请全局事务的提交/回滚。

积分服务中也有TM，但是由于没有用到，因此直接可以忽略。

我们如果使用 Spring框架的注解式事务，远程调用会在本地事务提交之前发生。但是，先发起远程调用还是先提交本地事务，这个其实没有任何影响。

第二阶段流程如：

第二阶段的逻辑就比较简单了。

Client和TC之间是有长连接的，如果是正常全局提交，则TC通知多个RM异步清理掉本地的redo和undo log即可。如果是回滚，则TC通知每个RM回滚数据即可。

这里就会引出一个问题，由于本地事务都是自己直接提交了，后面如何回滚，由于我们在操作本地业务操作的前后，做记录了undo和redo log，因此可以通过undo log进行回滚。

由于undo和redo log和业务操作在同一个事务中，因此肯定会同时成功或同时失败。

但是还会存在一个问题，因为每个事务从本地提交到通知回滚这段时间里，可能这条数据已经被别的事务修改，如果直接用undo log回滚，会导致数据不一致的情况。

此时，RM会用redo log进行校验，对比数据是否一样，从而得知数据是否有别的事务修改过。注意：undo log是被修改前的数据，可以用于回滚；redo log是被修改后的数据，用于回滚校验。

如果数据未被其他事务修改过，则可以直接回滚；如果是脏数据，再根据不同策略处理。

Seata AT 模式在电商下单场景的使用

下面描述 Seata AT mode 的工作原理使用的电商下单场景的使用

如下图所示：

在上图中，协调者 shopping-service 先调用参与者 repo-service 扣减库存，后调用参与者 order-service 生成订单。这个业务流使用 Seata in XA mode 后的全局事务流程如下图所示：

上图描述的全局事务执行流程为：

1）shopping-service 向 Seata 注册全局事务，并产生一个全局事务标识 XID

2）将 repo-service.repo_db、order-service.order_db 的本地事务执行到待提交阶段，事务内容包含对 repo-service.repo_db、order-service.order_db 进行的查询操作以及写每个库的 undo_log 记录

3）repo-service.repo_db、order-service.order_db 向 Seata 注册分支事务，并将其纳入该 XID 对应的全局事务范围

4）提交 repo-service.repo_db、order-service.order_db 的本地事务

5）repo-service.repo_db、order-service.order_db 向 Seata 汇报分支事务的提交状态

6）Seata 汇总所有的 DB 的分支事务的提交状态，决定全局事务是该提交还是回滚

7）Seata 通知 repo-service.repo_db、order-service.order_db 提交/回滚本地事务，若需要回滚，采取的是补偿式方法

其中 1）2）3）4）5）属于第一阶段，6）7）属于第二阶段。

电商业务场景中 Seata in AT mode 工作流程详述

在上面的电商业务场景中，购物服务调用库存服务扣减库存，调用订单服务创建订单，显然这两个调用过程要放在一个事务里面。即：

start global_trx call 库存服务的扣减库存接口 call 订单服务的创建订单接口 commit global_trx

在库存服务的数据库中，存在如下的库存表 t_repo：

在订单服务的数据库中，存在如下的订单表 t_order：

现在，id 为 40002 的用户要购买一只商品代码为 20002 的鼠标，整个分布式事务的内容为：

1）在库存服务的库存表中将记录

修改为

2）在订单服务的订单表中添加一条记录

以上操作，在 AT 模式的第一阶段的流程图如下：

从 AT 模式第一阶段的流程来看，分支的本地事务在第一阶段提交完成之后，就会释放掉本地事务锁定的本地记录。这是 AT 模式和 XA 最大的不同点，在 XA 事务的两阶段提交中，被锁定的记录直到第二阶段结束才会被释放。所以 AT 模式减少了锁记录的时间，从而提高了分布式事务的处理效率。AT 模式之所以能够实现第一阶段完成就释放被锁定的记录，是因为 Seata 在每个服务的数据库中维护了一张 undo_log 表，其中记录了对 t_order / t_repo 进行操作前后记录的镜像数据，即便第二阶段发生异常，只需回放每个服务的 undo_log 中的相应记录即可实现全局回滚。

undo_log 的表结构：

第一阶段结束之后，Seata 会接收到所有分支事务的提交状态，然后决定是提交全局事务还是回滚全局事务。

1）若所有分支事务本地提交均成功，则 Seata 决定全局提交。Seata 将分支提交的消息发送给各个分支事务，各个分支事务收到分支提交消息后，会将消息放入一个缓冲队列，然后直接向 Seata 返回提交成功。之后，每个本地事务会慢慢处理分支提交消息，处理的方式为：删除相应分支事务的 undo_log 记录。之所以只需删除分支事务的 undo_log 记录，而不需要再做其他提交操作，是因为提交操作已经在第一阶段完成了（这也是 AT 和 XA 不同的地方）。这个过程如下图所示：

分支事务之所以能够直接返回成功给 Seata，是因为真正关键的提交操作在第一阶段已经完成了，清除 undo_log 日志只是收尾工作，即便清除失败了，也对整个分布式事务不产生实质影响。

2）若任一分支事务本地提交失败，则 Seata 决定全局回滚，将分支事务回滚消息发送给各个分支事务，由于在第一阶段各个服务的数据库上记录了 undo_log 记录，分支事务回滚操作只需根据 undo_log 记录进行补偿即可。全局事务的回滚流程如下图所示：

这里对图中的 2、3 步做进一步的说明：

1）由于上文给出了 undo_log 的表结构，所以可以通过 xid 和 branch_id 来找到当前分支事务的所有 undo_log 记录；

2）拿到当前分支事务的 undo_log 记录之后，首先要做数据校验，如果 afterImage 中的记录与当前的表记录不一致，说明从第一阶段完成到此刻期间，有别的事务修改了这些记录，这会导致分支事务无法回滚，向 Seata 反馈回滚失败；如果 afterImage 中的记录与当前的表记录一致，说明从第一阶段完成到此刻期间，没有别的事务修改这些记录，分支事务可回滚，进而根据 beforeImage 和 afterImage 计算出补偿 SQL，执行补偿 SQL 进行回滚，然后删除相应 undo_log，向 Seata 反馈回滚成功。

Seata的数据隔离性

seata的at模式主要实现逻辑是数据源代理，而数据源代理将基于如MySQL和Oracle等关系事务型数据库实现，基于数据库的隔离级别为read committed。换而言之，本地事务的支持是seata实现at模式的必要条件，这也将限制seata的at模式的使用场景。

写隔离

从前面的工作流程，我们可以很容易知道，Seata的写隔离级别是全局独占的。

首先，我们理解一下写隔离的流程

1. 如上所示，一个分布式事务的锁获取流程是这样的
   1）先获取到本地锁，这样你已经可以修改本地数据了，只是还不能本地事务提交
   2）而后，能否提交就是看能否获得全局锁
   3）获得了全局锁，意味着可以修改了，那么提交本地事务，释放本地锁
   4）当分布式事务提交，释放全局锁。这样就可以让其它事务获取全局锁，并提交它们对本地数据的修改了。

可以看到，这里有两个关键点
1）本地锁获取之前，不会去争抢全局锁
2）全局锁获取之前，不会提交本地锁

这就意味着，数据的修改将被互斥开来。也就不会造成写入脏数据。全局锁可以让分布式修改中的写数据隔离。

写隔离的原则：

• 一阶段本地事务提交前，需要确保先拿到 全局锁 。
• 拿不到 全局锁 ，不能提交本地事务。
• 拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

以一个示例来说明：

两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。

tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 全局锁 ，本地提交释放本地锁。

tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 全局锁 ，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。

tx1 二阶段全局提交，释放 全局锁 。tx2 拿到 全局锁 提交本地事务。

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生 脏写 的问题。

读的隔离级别

在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted） 。

如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

SELECT FOR UPDATE 语句的执行会申请 全局锁 ，如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是 已提交 的，才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

Spring Cloud集成Seata AT模式

AT模式是指Automatic (Branch) Transaction Mode 自动化分支事务，使用AT模式的前提是

• 基于支持本地 ACID 事务的关系型数据库。
• Java 应用，通过 JDBC 访问数据库。

seata-at的使用步骤

1、引入seata框架，配置好seata基本配置，建立undo_log表

2、消费者引入全局事务注解@GlobalTransactional

3、生产者引入全局事务注解@GlobalTransactional

此处没有写完， 尼恩的博文，都是迭代模式，后续会持续

Seata TCC 模式

简介

TCC 与 Seata AT 事务一样都是两阶段事务，它与 AT 事务的主要区别为：

• TCC 对业务代码侵入严重
  每个阶段的数据操作都要自己进行编码来实现，事务框架无法自动处理。
• TCC 性能更高
  不必对数据加全局锁，允许多个事务同时操作数据。

  

Seata TCC 整体是 两阶段提交 的模型。一个分布式的全局事务，全局事务是由若干分支事务组成的，分支事务要满足 两阶段提交 的模型要求，即需要每个分支事务都具备自己的：

• 一阶段 prepare 行为
• 二阶段 commit 或 rollback 行为

根据两阶段行为模式的不同，我们将分支事务划分为 Automatic (Branch) Transaction Mode 和 TCC (Branch) Transaction Mode.

AT 模式（参考链接 TBD）基于 支持本地 ACID 事务 的 关系型数据库：

• 一阶段 prepare 行为：在本地事务中，一并提交业务数据更新和相应回滚日志记录。
• 二阶段 commit 行为：马上成功结束，自动 异步批量清理回滚日志。
• 二阶段 rollback 行为：通过回滚日志，自动 生成补偿操作，完成数据回滚。

相应的，TCC 模式，不依赖于底层数据资源的事务支持：

• 一阶段 prepare 行为：调用 自定义 的 prepare 逻辑。
• 二阶段 commit 行为：调用 自定义 的 commit 逻辑。
• 二阶段 rollback 行为：调用 自定义 的 rollback 逻辑。

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

第一阶段 Try

以账户服务为例，当下订单时要扣减用户账户金额：

假如用户购买 100 元商品，要扣减 100 元。

TCC 事务首先对这100元的扣减金额进行预留，或者说是先冻结这100元：

第二阶段 Confirm

如果第一阶段能够顺利完成，那么说明“扣减金额”业务(分支事务)最终肯定是可以成功的。当全局事务提交时， TC会控制当前分支事务进行提交，如果提交失败，TC 会反复尝试，直到提交成功为止。

当全局事务提交时，就可以使用冻结的金额来最终实现业务数据操作：

第二阶段 Cancel

如果全局事务回滚，就把冻结的金额进行解冻，恢复到以前的状态，TC 会控制当前分支事务回滚，如果回滚失败，TC 会反复尝试，直到回滚完成为止。

多个事务并发的情况

多个TCC全局事务允许并发，它们执行扣减金额时，只需要冻结各自的金额即可：

Seata TCC 模式 没有写完， 尼恩的博文，都是迭代模式，后续会持续优化

SEATA Saga 模式

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

理论基础：Hector & Kenneth 发表论⽂ Sagas （1987）

适用场景：

• 业务流程长、业务流程多
• 参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口

优势：

• 一阶段提交本地事务，无锁，高性能
• 事件驱动架构，参与者可异步执行，高吞吐
• 补偿服务易于实现

缺点：

• 不保证隔离性（应对方案见后面文档）

Saga的实现：

基于状态机引擎的 Saga 实现：

目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：

1. 通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
2. 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
3. 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚

注意: 异常发生时是否进行补偿也可由用户自定义决定

1. 可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能

示例状态图:

Seata Saga 模式 没有写完， 尼恩的博文，都是迭代模式，后续会持续优化

Seata XA 模式

使用Seata XA 模式的前提

• 支持XA 事务的数据库。
• Java 应用，通过 JDBC 访问数据库。

Seata XA 模式的整体机制

在 Seata 定义的分布式事务框架内，利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种 事务模式。

注意这里的重点：利用事务资源对 XA 协议的支持，以 XA 协议的机制来管理分支事务。

Seata XA 模式的工作机制

1. 整体运行机制

XA 模式 运行在 Seata 定义的事务框架内：

2. 数据源代理

XA 模式需要 XAConnection。

获取 XAConnection 两种方式：

• 方式一：要求开发者配置 XADataSource
• 方式二：根据开发者的普通 DataSource 来创建

第一种方式，给开发者增加了认知负担，需要为 XA 模式专门去学习和使用 XA 数据源，与 透明化 XA 编程模型的设计目标相违背。

第二种方式，对开发者比较友好，和 AT 模式使用一样，开发者完全不必关心 XA 层面的任何问题，保持本地编程模型即可。

我们优先设计实现第二种方式：数据源代理根据普通数据源中获取的普通 JDBC 连接创建出相应的 XAConnection。

类比 AT 模式的数据源代理机制，如下：

实际上，这种方法是在做数据库驱动程序要做的事情。不同的厂商、不同版本的数据库驱动实现机制是厂商私有的，我们只能保证在充分测试过的驱动程序上是正确的，开发者使用的驱动程序版本差异很可能造成机制的失效。

这点在 Oracle 上体现非常明显。参见 Druid issue：DruidXADataSource不能正常工作在ORACLE上 · Issue #3707 · alibaba/druid · GitHub

综合考虑，XA 模式的数据源代理设计需要同时支持第一种方式：基于 XA 数据源进行代理。

类比 AT 模式的数据源代理机制，如下：

XA start 需要 Xid 参数。

这个 Xid 需要和 Seata 全局事务的 XID 和 BranchId 关联起来，以便由 TC 驱动 XA 分支的提交或回滚。

目前 Seata 的 BranchId 是在分支注册过程，由 TC 统一生成的，所以 XA 模式分支注册的时机需要在 XA start 之前。

将来一个可能的优化方向：

把分支注册尽量延后。类似 AT 模式在本地事务提交之前才注册分支，避免分支执行失败情况下，没有意义的分支注册。

这个优化方向需要 BranchId 生成机制的变化来配合。BranchId 不通过分支注册过程生成，而是生成后再带着 BranchId 去注册分支。

XA 模式的使用

从编程模型上，XA 模式与 AT 模式保持完全一致。

可以参考 Seata 官网的样例：seata-xa

样例场景是 Seata 经典的，涉及库存、订单、账户 3 个微服务的商品订购业务。

在样例中，上层编程模型与 AT 模式完全相同。只需要修改数据源代理，即可实现 XA 模式与 AT 模式之间的切换。

1. @Bean("dataSource")

2. public DataSource dataSource(DruidDataSource druidDataSource) {

3. // DataSourceProxy for AT mode

4. // return new DataSourceProxy(druidDataSource);

6. // DataSourceProxyXA for XA mode

7. return new DataSourceProxyXA(druidDataSource);

8. }

一键获取完整项目代码

面试题标准答案: 如何解决分布式事务问题的？

现在Java面试，分布式系统、分布式事务几乎是标配。而分布式系统、分布式事务本身比较复杂，大家学起来也非常头疼。

面试题：分布式事务了解吗？你们是如何解决分布式事务问题的？

Seata AT模式和Seata TCC是在生产中最常用。

• 强一致性模型，Seata AT 强一致方案 模式用于强一致主要用于核心模块，例如交易/订单等。
• 弱一致性模型。Seata TCC 弱一致方案一般用于边缘模块例如库存，通过TC的协调，保证最终一致性，也可以业务解耦。

面试中如果你真的被问到，可以分场景回答：

（1）强一致性场景

对于那些特别严格的场景，用的是Seata AT模式来保证强一致性；

准备好例子：你找一个严格要求数据绝对不能错的场景（如电商交易交易中的库存和订单、优惠券），可以回答使用成熟的如中间件Seata AT模式。

阿里开源了分布式事务框架seata经历过阿里生产环境大量考验的框架。 seata支持Dubbo，Spring Cloud。

是Seata AT模式，保障强一致性，支持跨多个库修改数据；

• 订单库：增加订单
• 商品库：扣减库存
• 优惠券库：预扣优惠券

（2）弱一致性场景

对于数据一致性要求没有那些特别严格、或者由不同系统执行子事务的场景，可以回答使用Seata TCC 保障弱一致性方案

准备好例子：一个不是严格对数据一致性要求、或者由不同系统执行子事务的场景，如电商订单支付服务，更新订单状态，发送成功支付成功消息，只需要保障弱一致性即可。

Seata TCC 模式，保障弱一致性，支持跨多个服务和系统修改数据，在上面的场景中，使用Seata TCC 模式事务

• 订单服务：修改订单状态
• 通知服务：发送支付状态

（3）最终一致性场景

基于可靠消息的最终一致性，各个子事务可以较长时间内异步，但数据绝对不能丢的场景。可以使用异步确保型事务事。

可以使用基于MQ的异步确保型事务，比如电商平台的通知支付结果：

• 积分服务：增加积分
• 会计服务：生成会计记录

各大模式的总体对比：

属性	2PC	TCC	Saga	异步确保型事务	尽最大努力通知
事务一致性	强	弱	弱	弱	弱
复杂性	中	高	中	低	低
业务侵入性	小	大	小	中	中
使用局限性	大	大	中	小	中
性能	低	中	高	高	高
维护成本	低	高	中	低	中