分布式 - 分布式事务面试题

 

1 分布式事务面试题

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

最为常见的面试题：

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

（标准答案：见末尾）

问题1、分布式事务产生的背景？

在传统的单体项目中，多个不同的业务逻辑使用的都是同一个数据源，使用的都是同一个事务管理器，所以不会存在事务问题。
在分布式或者微服务架构中，每个服务都有自己的数据源，使用不同事务管理器，如果A服务去调用B服务，B服务执行失败了，A服务的事务和B服务的事务都会回滚，这时候是不存在事务问题的，但是如果A服务B服务执行成功之后出现异常，A服务的事务会回滚，但是B服务的事务不会回滚，此时就存在分布式事务问题。
（在单体的项目中，有多个不同的数据源，每个数据源中都有自己独立的事务管理器，互不影响，那么这时候也会存在多数据源事务管理：解决方案jta+ atominc）

问题2、常见的分布式事务解决方案？

1、使用MQ
2、使用LCN
3、使用Seata
4、2PC、3PC

问题3、什么是Seata？

Seata是阿里巴巴退出的一款用来解决分布式事务问题的框架，他经过天猫双十一的考验，很有可能成为解决分布式事务问题的主流框架

问题4、Seata分布式事务框架实现原理？

Seata有三个组成部分：事务协调器TC：协调者、事务管理器TM：发起方、资源管理器RM：参与方
（1）发起方会向协调者申请一个全局事务id，并保存到ThreadLocal中（为什么要保存到ThreadLocal中？弱引用，线程之间不会发生数据冲突）
（2）Seata数据源代理发起方和参与方的数据源，将前置镜像和后置镜像写入到undo_log表中，方便后期回滚使用
（3）发起方获取全局事务id，通过改写Feign客户端请求头传入全局事务id。
（4）参与方从请求头中获取全局事务id保存到ThreadLocal中，并把该分支注册到SeataServer中。
（5）如果没有出现异常，发起方会通知协调者，协调者通知所有分支，通过全局事务id和本地事务id删除undo_log数据，如果出现异常，通过undo_log逆向生成sql语句并执行，然后删除undo_log语句。如果处理业务逻辑代码超时，也会回滚。

问题5、SpringBoot如何整合Seata?

一般情况下，学一个知识不需要去学API，学的主要是思想，API会发生变化，思想几乎是不会变的
第一步：引入依赖
第二步：bin下的file文件和registry文件放入到每个项目中，并修改，分组名称要保持一致
第三步：yml配置seata
第四步：引入DataSourceProxy配置文件

问题6、Seata和LCN的区别？

Seata和LCN的思想是一样的，只不过LCN中采用的是假关闭，不会提交或者回滚事务，而Seata中是直接插入数据。两者的区别就是当发起方突然宕机了，LCN会发生死锁，而Seata不会，但是Seata会引起脏读。
LCN实现分布式事务三种方案(模式)：LCN、TCC、TXC
Seata实现分布式事务四种方案(模式)：AT（几乎等于LCN）TCC、SA、GAXA

系列问题： 分布式事务相关的概念介绍？

概念	说明
分布式事务	横跨多个服务，操作多个数据库；跨库、分库分表、分服务
DTP 模型	DTP模型的5个基本元素：应用程序 AP 资源管理器 RM 事务管理器 TM通信资源管理器 CRM 通信协议 CP
XA规范	定义了RM-TM的交互接口
两阶段提交协议 2PC	两阶段提交协议存在问题：1、同步阻塞问题。 2、单点故障。 3、数据不一致。
三阶段提交协议 3PC	协调者、参与者都引入了超时机制；三阶段 CanCommit、PreCommit（其中一个超时或者执行失败，则TM发起中断）和doCommit 3PC :优点 ：引入超时机制，降低了协调者与参与者之间的阻塞范围；缺点：在参与者接收到preCommit之后，如果出现网络分区，那么该参与者节点会继续执行事务的提交，而其他节点会执行中断事务，最终会造成数据的不一致。
CAP 定理BASE理论	CAP : 大规模的分布式系统时会遇到三个特性：一致性（consistency）、可用性（Availability）、分区容错（partition-tolerance ）最多只能满足其中的2项 BASE理论 ： 基本可用、软状态、最终一致
刚性事务、柔性事务	刚性事务–强一致性 两阶段提交协议（2PC） 柔性事务–最终一致性 TCC（两阶段型、补偿型）、最大努力通知、可靠消息最终一致
TCC（两阶段型、补偿型）	Try阶段： 完成所有业务检查（一致性），预留业务资源(准隔离性)**Confirm阶段：**确认执行业务操作，不做任何业务检查， 只使用Try阶段预留的业务资源。Cancel阶段： 取消Try阶段预留的业务资源。
TCC 与 XA	XA是资源层面的分布式事务，强一致性 ，一直会持有资源的锁；TCC是业务层面的分布式事务，最终一致性，不会一直持有资源的锁 TCC :优点：避免了XA两阶段提交占用资源锁时间过长导致的性能低下问题缺点：主业务服务和从业务服务都需要进行改造，从业务方改造成本更
最大努力通知型如银行通知、商户通知等	最简单的一种柔性事务 1、不可靠消息：业务活动主动方，在完成业务处理之后，向业务活动的被动方发送消息，直到通知N次后不再通知，允许消息丢失(不可靠消息)。 2、定期校对：业务活动的被动方，根据定时策略，向业务活动主动方查询(主动方提供查询接口)，恢复丢失的业务消息。
可靠消息最终一致	RocketMQ的事务消息机制

2 事务简介

事务(Transaction)是操作数据库中某个数据项的一个程序执行单元(unit)。事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

（1）原子性（atomicity）：个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。

事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。

比方说：买东西要么交钱收货一起都执行，要么发不出货，就退钱

（2）一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态。一个事务查看数据时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。

如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。

如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。

（3）隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。

比方说：一个人买东西这个事情，是不影响其他人买东西。

隔离性又分为四个级别：读未提交(read uncommitted)、读已提交(read committed，解决脏读)、可重复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。

（4）持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

比方说：一个人买东西的时候需要记录在账本上，即使老板忘记了那也有据可查。

1.1.2 MySQL的事务实现方案

大多数场景下，我们的应用都只需要操作单一的数据库，这种情况下的事务称之为本地事务(Local Transaction)。本地事务的ACID特性是数据库直接提供支持。

大部分人对 MySQL 都比较熟悉，以MySQL 的InnoDB （InnoDB 是 MySQL 的一个存储引擎）为例，介绍一下单一数据库的事务实现原理。

InnoDB 是通过 日志和锁 来保证的事务的 ACID特性，具体如下：

（1）通过数据库锁的机制，保障事务的隔离性；

（2）通过 Redo Log（重做日志）来，保障事务的持久性；

（3）通过 Undo Log （撤销日志）来，保障事务的原子性；

（4）通过 Undo Log （撤销日志）来，保障事务的一致性；

Undo Log 如何保障事务的原子性呢？

具体的方式为：在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为 Undo Log），然后进行数据的修改。如果出现了错误或者用户执行了 Rollback 语句，系统可以利用 Undo Log 中的备份将数据恢复到事务开始之前的状态。

Redo Log如何保障事务的持久性呢？

具体的方式为：Redo Log 记录的是新数据的备份（和 Undo Log 相反）。在事务提交前，只要将 Redo Log 持久化即可，不需要将数据持久化。当系统崩溃时，虽然数据没有持久化，但是 Redo Log 已经持久化。系统可以根据 Redo Log 的内容，将所有数据恢复到崩溃之前的状态。

1.1.3 什么是分布式事务？

对于分布式系统而言，需要保证分布式系统中的数据一致性，保证数据在子系统中始终保持一致，避免业务出现问题。分布式系统中对数要么一起成功，要么一起失败，必须是一个整体性的事务。

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

简单的说，在分布式系统上一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

举个例子：在电商网站中，用户对商品进行下单，需要在订单表中创建一条订单数据，同时需要在库存表中修改当前商品的剩余库存数量，两步操作一个添加，一个修改，我们一定要保证这两步操作一定同时操作成功或失败，否则业务就会出现问题。

任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务。对于分布式事务而言，即使不能都很好的满足，也要考虑支持到什么程度。

典型的分布式事务场景：

1. 跨库事务

跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。笔者见过一个相对比较复杂的业务，一个业务中同时操作了9个库。下图演示了一个服务同时操作2个库的情况：

2. 分库分表

通常一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。如下图，将数据库B拆分成了2个库：

对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。如，对于sql：insert into user(id,name) values (1,“tianshouzhi”),(2,“wangxiaoxiao”)。这条sql是操作单库的语法，单库情况下，可以保证事务的一致性。

但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。

3. 服务化(SOA)

微服务架构是目前一个比较一个比较火的概念。例如上面笔者提到的一个案例，某个应用同时操作了9个库，这样的应用业务逻辑必然非常复杂，对于开发人员是极大的挑战，应该拆分成不同的独立服务，以简化业务逻辑。拆分后，独立服务之间通过RPC框架来进行远程调用，实现彼此的通信。下图演示了一个3个服务之间彼此调用的架构：

Service A完成某个功能需要直接操作数据库，同时需要调用Service B和Service C，而Service B又同时操作了2个数据库，Service C也操作了一个库。需要保证这些跨服务的对多个数据库的操作要不都成功，要不都失败，实际上这可能是最典型的分布式事务场景。

分布式事务实现方案必须要考虑性能的问题，如果为了严格保证ACID特性，导致性能严重下降，那么对于一些要求快速响应的业务，是无法接受的。

3 分布式事务的理论基础

数据库事务ACID 四大特性，无法满足分布式事务的实际需求，这个时候又有一些新的大牛提出一些新的理论。

1.2.1 CAP定理

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：

• 一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)

• 可用性(Availability) ： 每个操作都必须以可预期的响应结束

• 分区容错性(Partition tolerance) ： 即使出现单个组件无法可用，操作依然可以完成

具体地讲在分布式系统中，一个Web应用至多只能同时支持上面的两个属性。因此，设计人员必须在一致性与可用性之间做出选择。

2000年7月Eric Brewer教授仅仅提出来的是一个猜想，2年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP理论，并且而一个分布式系统最多只能满足CAP中的2项。之后，CAP理论正式成为分布式计算领域的公认定理。

所以，CAP定理在迄今为止的分布式系统中都是适用的！

CAP的一致性、可用性、分区容错性 具体如下：

1. 数据一致性

数据一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。

例如对于电商系统用户下单操作，库存减少、用户资金账户扣减、积分增加等操作必须在用户下单操作完成后必须是一致的。不能出现类似于库存已经减少，而用户资金账户尚未扣减，积分也未增加的情况。如果出现了这种情况，那么就认为是不一致的。

数据一致性分为强一致性、弱一致性、最终一致性。

• 如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的，那么称之为强一致性。

• 如果允许存在中间状态，只要求经过一段时间后，数据最终是一致的，则称之为最终一致性。

• 此外，如果允许存在部分数据不一致，那么就称之为弱一致性。

面试题：什么是数据一致性？

现在知道怎么回答了吧！

 

• 1
• 2
• 3

2. 可用性

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有限的时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。

试想，如果一个下单操作，为了保证分布式事务的一致性，需要10分钟才能处理完，那么用户显然是无法忍受的。“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果，不论这个结果是成功还是失败。

3. 分区容错性

分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

CAP理论已经被证明：一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，我们就需要抛弃一个。

但分区容错性是不能被抛弃的那个，为什么呢？对于一个分布式系统而言，分区容错性是一个最基本的要求。因为既然是一个分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了。而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。

既然分区容错性不能抛弃，那么，只能在一致性、可用性寻找平衡。因此系统架构师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间做取舍。

而前面我们提到的X/Open XA 两阶段提交协议的分布式事务方案，强调的就是一致性；由于可用性较低，实际应用的并不多。而基于BASE理论的柔性事务，强调的是可用性，目前大行其道，大部分互联网公司采可能会优先采用这种方案。

1.2.2 BASE理论

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论。文章链接：https://queue.acm.org/detail.cfm?id=1394128

BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。

1. 基本可用（Basically Available）

指分布式系统在出现不可预知故障的时候，允许损失部分可用性。

1. 软状态（ Soft State）

指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。

1. 最终一致（ Eventual Consistency）

强调的是所有的数据更新操作，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的。它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

4 分布式事务的主要方案

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

• 两阶段提交方案XA 方案

• TCC 方案

• 本地消息表

• 可靠消息最终一致性方案

• 最大努力通知方案

分为两个大类：

1. CAP理论的事务方案：

• 两阶段提交方案/XA方案

2. BAS柔性事务方案：

• TCC（两阶段型、补偿型）

• 本地消息表

• 可靠消息最终一致性（异步确保型）

• 最大努力通知（非可靠消息、定期校对）

1.3.3 两阶段提交模式（2PC）的XA 方案

2PC(2 phase commit)是一种分布式事务进行两段事务提交的简称，JavaEE的JTA/XA是2PC一种实现。2PC适合有多个数据源情况下统一按照ACID原则完成操作，比如一个操作涉及三个数据库的三个表a b c，如何保证这三个表的数据同时操作完成，保证在同一逻辑下的一致性，这是2PC关注所在，如果没有2PC，有可能a表修改成功，b表和c表没有修改成功，那么就出现不一致性。

对数据库分布式事务有了解的同学一定知道数据库支持的两阶段提交（2PC），又叫做 XA Transactions。MySQL从5.5版本开始支持，SQL Server 2005 开始支持，Oracle 7 开始支持。

其中，XA 是一个两阶段提交协议，该协议分为以下两个阶段：

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据。

其中，如果有任何一个数据库否决此次提交，那么所有数据库都会被要求回滚它们在此事务中的那部分信息。这样做的缺陷是什么呢? 咋看之下我们可以在数据库分区之间获得一致性。

XA 的失败处理:

XA 方案中，有一个事务管理器的角色，负责协调多个数据库（资源管理器）的事务，事务管理器先问问各个数据库你准备好了吗？如果每个数据库都回复 ok，那么就正式提交事务，在各个数据库上执行操作；如果任何其中一个数据库回答不 ok，那么就回滚事务。

XA 方案比较适合单体应用里，跨多个库的分布式事务，而且因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景。如果要玩儿，那么基于 spring + JTA 就可以搞定，自己随便搜个 demo 看看就知道了。

XA 方案实际很少用，一般来说某个系统内部如果出现跨多个库的这么一个操作，是不合规的。我可以给大家介绍一下， 现在微服务，一个大的系统分成几百个服务，几十个服务。一般来说，我们的规定和规范，是要求每个服务只能操作自己对应的一个数据库。

如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。

如果你要操作别人的服务的库，你必须是通过调用别的服务的接口来实现，绝对不允许交叉访问别人的数据库。

1.3.4 TCC 方案

TCC 方案的全称是：Try、Confirm、Cancel。

l Try 阶段：对各个服务的资源做检测以及对资源进行锁定或者预留。

l Confirm 阶段：在各个服务中执行实际的操作。

l Cancel 阶段：如果任何一个服务的业务方法执行出错，那么这里就需要进行补偿动作。补偿动作具体来说，就是对已经执行成功的业务逻辑的回滚操作。

TCC 方案严重依赖回滚和补偿代码，最终的结果是：回滚代码逻辑复杂，业务代码很难维护。所以，TCC 方案的使用场景较少，但是也有使用的场景。

比如说跟钱打交道的，支付、交易相关的场景，大家会用 TCC方案，严格保证分布式事务要么全部成功，要么全部自动回滚，严格保证资金的正确性，保证在资金上不会出现问题。

更加详细的流程如下：

1.3.5 本地消息表

本地消息表其实是国外的 ebay 搞出来的这么一套思想。

这个大概意思是这样的：

（1）A 系统在自己本地一个事务里操作同时，插入一条数据到消息表；

（2）接着 A 系统将这个消息发送到 MQ 中去；

（3）B 系统接收到消息之后，在一个事务里，往自己本地消息表里插入一条数据，同时执行其他的业务操作，如果这个消息已经被处理过了，那么此时这个事务会回滚，这样保证不会重复处理消息；

（4）B 系统执行成功之后，就会更新自己本地消息表的状态以及 A 系统消息表的状态；

（5）如果 B 系统处理失败了，那么就不会更新消息表状态，那么此时 A 系统会定时扫描自己的消息表，如果有未处理的消息，会再次发送到 MQ 中去，让 B 再次处理；

（6）这个方案保证了最终一致性，哪怕 B 事务失败了，但是 A 会不断重发消息，直到 B 那边成功为止。

这个方案说实话最大的问题就在于严重依赖于数据库的消息表来管理事务啥的，会导致如果是高并发场景咋办呢？咋扩展呢？所以一般确实很少用。

一个类似的流程如下：

一个类似的流程如下：

1.3.6 可靠消息最终一致性方案

这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。比如阿里的 RocketMQ 就支持消息事务。

大概的意思就是：

（1）A 系统先发送一个 prepared 消息到 mq，如果这个 prepared 消息发送失败那么就直接取消操作别执行了；

（2）如果这个消息发送成功过了，那么接着执行本地事务，如果成功就告诉 mq 发送确认消息，如果失败就告诉 mq 回滚消息；

（3）如果发送了确认消息，那么此时 B 系统会接收到确认消息，然后执行本地的事务；

（4）mq 会自动定时轮询所有 prepared 消息回调你的接口，问你，这个消息是不是本地事务处理失败了，所有没发送确认的消息，是继续重试还是回滚？一般来说这里你就可以查下数据库看之前本地事务是否执行，如果回滚了，那么这里也回滚吧。这个就是避免可能本地事务执行成功了，而确认消息却发送失败了。

（5）这个方案里，要是系统 B 的事务失败了咋办？重试咯，自动不断重试直到成功，如果实在是不行，要么就是针对重要的资金类业务进行回滚，比如 B 系统本地回滚后，想办法通知系统 A 也回滚；或者是发送报警由人工来手工回滚和补偿。

这个还是比较合适的，目前国内互联网公司大都是这么玩儿的，要不你举用 RocketMQ 支持的，要不你就自己基于类似 ActiveMQ？RabbitMQ？自己封装一套类似的逻辑出来，总之思路就是这样子的。

1.3.7 最大努力通知方案

这个方案的大致意思就是：

（1）系统 A 本地事务执行完之后，发送个消息到 MQ；

（2）这里会有个专门消费 MQ 的最大努力通知服务，这个服务会消费 MQ 然后写入数据库中记录下来，或者是放入个内存队列也可以，接着调用系统 B 的接口；

（3）要是系统 B 执行成功就 ok 了；要是系统 B 执行失败了，那么最大努力通知服务就定时尝试重新调用系统 B，反复 N 次，最后还是不行就放弃。

1.4 面试中如何应答？

TCC和可靠消息最终一致性方案是在生产中最常用。

一个要求强一致，一个要求最终一致。

TCC用于强一致主要用于核心模块，例如交易/订单等。最终一致方案一般用于边缘模块例如库存，通过mq去通知，保证最终一致性，也可以业务解耦。

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

（1）对于那些特别严格的场景，用的是 TCC 来保证强一致性；

准备好例子：你找一个严格要求数据绝对不能错的场景（如电商交易交易中的资金），可以回答使用成熟的如中间件如阿里分布式事务seata组件。

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

 

• 1
• 2
• 3

（2）对于数据一致性要求没有那些特别严格的场景，可以回答使用可靠消息最终一致性方案，如果基于 RocketMQ 来实现了分布式事务框架，也
基于ActiveMQ，RabbitMQ, RocketMQ等，自己开发一个可靠消息服务，收到消息之后，尝试投递到MQ，如果投递失败，重试投递。

准备好例子：你找一个严格对数据一致性要求没有那么严格的场景，如电商订单插入之后要调用库存服务更新库存，库存数据没有那么严格，比如少一点点也行，只需要保障最终一致性即可。

现在大量用RocketMQ，作为MQ中间件，
RocketMQ提供了分布式事务支持，已经把可靠消息服务需要实现的功能逻辑已经做好了。

 

• 1
• 2

参考文献：
1 http://www.tianshouzhi.com/api/tutorials/distributed_transaction
2 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
3 https://zhuanlan.zhihu.com/p/25933039
4 https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html