文章目录

• 微服务下的分布式事务介绍及其解决方案（java）
• • 第一部分
  • • 7.11分布式(XA) 事务
    • • 7.11.1内部XA事务
      • 7.11.2 外部XA事务
  • 第二部分
  • • 1、什么是分布式事务
    • • 1.1、事务的ACID特性
      • • 1.1.1、原子性（A）
        • 1.1.2、一致性（C）
        • 1.1.3、隔离性（I）
        • 1.1.4、持久性（D）
    • 2、分布式事务的产生的原因
    • • 2.1、数据库分库分表
      • 2.2、应用SOA化
    • 3、分布式事务的应用场景
    • • 3.1、支付
      • 3.2、在线下单
    • 4、分布式理论
    • • 4.1、CAP定理
      • • 4.1.1、分布式系统能否兼顾C、A、P？
        • 4.1.2、CAP有哪些组合方式？
        • 4.1.3、注意：不是所谓的3选2（不要被网上大多数文章误导了）:
      • 4.2、BASE理论
      • • 4.2.1、BASE理论的核心思想
        • 4.2.2、BASE理论三要素
    • 5、常见的分布式事务解决方案
    • • 5.1、基于XA协议的两阶段提交（2pc）
      • • 5.1.1、 存在的问题：
      • 5.2、MQ消息事务+最终一致性
      • • 5.2.1、第二种解释
      • 5.3、补偿事务（TCC）
      • 5.4、本地消息表（异步确保）
    • 6、总结

微服务下的分布式事务介绍及其解决方案（java）

第一部分

这一部分是 高性能MySQL（第3版）中第七章第11节内容：关于MySQL高级特性之分布式（XA）事务的介绍，（不感兴趣的可以忽略）

7.11分布式(XA) 事务

存储引擎的事务特性能够保证在存储引擎级别实现ACID (参考前面介绍的“事务”的四大特性：原子性，一致性，隔离性，持久性)，而分布式事务则让存储引擎级别的ACID可以扩展到数据库层面，甚至可以扩展到多个数据库之间一这需要通过两阶段提交实现。MySQL5.0和更新版本的数据库已经开始支持XA事务了。

XA事务中需要有一个事务协调器来保证所有的事务参与者都完成了准备工作(第一阶段)。如果协调器收到所有的参与者都准备好的消息，就会告诉所有的事务可以提交了，这是第二阶段。MySQL在这个XA事务过程中扮演一个参与者的角色，而不是协调者。

实际上，在MySQL中有两种XA事务。一方面，MySQL可以参与到外部的分布式事务中；另一方面，还可以通过XA事务来协调存储引擎和二进制日志。

7.11.1内部XA事务

MySQL本身的插件式架构导致在其内部需要使用XA事务。MySQL中各个存储引擎是完全独立的，彼此不知道对方的存在，所以一个跨存储引擎的事务就需要一个外部的协调者。如果不使用XA协议，例如，跨存储引擎的事务提交就只是顺序地要求每个存储引擎各自提交。如果在某个存储提交过程中发生系统崩溃，就会破坏事务的特性(要么就全部提交，要么就不做任何操作)。

如果将MySQL记录的二进制日志操作看作一个独立的“存储引擎”，就不难理解为什么即使是一个存储引擎参与的事务仍然需要XA事务了。在存储引擎提交的同时，需要将“提交”的信息写入二进制日志，这就是一个分布式事务，只不过二进制日志的参与者是MySQL本身。

XA事务为MySQL带来巨大的性能下降。从MySQL5.0开始,它破坏了MySQL内部的“批量提交”(一种通过单磁盘I/O操作完成多个事务提交的技术)，使得MySQL不得不进行多次额外的fsync()调用（注15：在撰写 本书的时候，“批量提交“ 的问题已经有了很多解决方案，其中至少有三种是很优秀的。还需要进一步观察到底MySQL官方会采用哪一种，到底到哪个版本MySQL才会合并到源码。目前，使用MariaDB和Percona Server就可以避免这个问题）。

具体的，一个事务如果开启了二进制日志，则不仅需要对二进制日志进行持久化操作, InnoDB事务日志还需要两次日志持久化操作。换句话说，如果希望有二进制日志安全的事务实现，则至少需要做三次fsync()操作。唯一避免这个问题的办法就是关闭二进制日志，并将innodb_ support_ xa 设置为0（注16:一个常见的误区是认为innodb_support_xa只有在需要XA事务时才需要打开。这是错误的:该参数还会控制MyQSL内部存储引擎和二进制日志之间的分布式事务。如果你真正关心你的数据,你需要将这个参数打开）。

但这样的设置是非常不安全的，而且这会导致MySQL复制也没法正常工作。复制需要二进制日志和XA事务的支持，另外一-如果希望数据尽可能安全一.最好还要将sync_ binlog 设置成1,这时存储引擎和二进制日志才是真正同步的。(否则，XA事务支持就没有意义了，因为事务提交了二进制日志却可能没有“提交”到磁盘.)这也是为什么我们强烈建议使用带电池保护的RAID卡写缓存:这个缓存可以大大加快fsync()操作的效率。

下一章我们将更进一步地介绍如何配置事务日志和二进制日志。

7.11.2 外部XA事务

MySQL能够作为参与者完成一个外部的分布式事务。但它对XA协议支持并不完整，例如，XA协议要求在一个事务中的多个连接可以做关联，但目前的MySQL版本还不能支持。

因为通信延迟和参与者本身可能失败，所以外部XA事务比内部消耗会更大。如果在广域网中使用XA事务，通常会因为不可预测的网络性能导致事务失败。如果有太多不可控因素，例如，不稳定的网络通信或者用户长时间地等待而不提交，则最好避免使用XA事务。任何可能让事务提交发生延迟的操作代价都很大，因为它影响的不仅仅是自己本身，它还会让所有参与者都在等待。

通常，还可以使用别的方式实现高性能的分布式事务。例如，可以在本地写入数据，并将其放入队列，然后在一个更小、更快的事务中自动分发。还可以使用MySQL本身的复制机制来发送数据。我们看到很多应用程序都可以完全避免使用分布式事务。

也就是说，XA事务是一种在多个服务器之间同步数据的方法。如果由于某些原因不能使用MySQL本身的复制，或者性能并不是瓶颈的时候，可以尝试使用。

第二部分

官网中关于分布式（XA）事务的介绍： https://dev.mysql.com/doc/refman/5.7/en/xa.html

1、什么是分布式事务

先来看一下什么是本地事务？本地事务就是用关系数据库来控制事务，关系数据库通常都具有ACID特性，传统的单体应用通常会将数据全部存储在一个数据库中，会借助关系数据库来完成事务控制。

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上，以上是百度百科的解释。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

（1）在分布式系统中一次操作由多个系统协同完成，这种一次事务操作涉及多个系统通过网络协同完成的过程称为分布式事务。这里强调的是多个系统通过网络协同完成一个事务的过程，并不强调多个系统访问了不同的数据库，即使多个系统访问的是同一个数据库也是分布式事务，如下图

（2）另外一种分布式事务的表现是，一个应用程序使用了多个数据源连接了不同的数据库，当一次事务需要操作多个数据源，此时也属于分布式事务，当系统作了数据库拆分后会出现此种情况。

上面两种分布式事务表现形式第一种用的最多

1.1、事务的ACID特性

1.1.1、原子性（A）

所谓的原子性就是说，在整个事务中的所有操作，要么全部完成，要么全部不做，没有中间状态。对于事务在执行中发生错误，所有的操作都会被回滚，整个事务就像从没被执行过一样。

1.1.2、一致性（C）

事务的执行必须保证系统的一致性，就拿转账为例，A有500元，B有300元，如果在一个事务里A成功转给B50元，那么不管并发多少，不管发生什么，只要事务执行成功了，那么最后A账户一定是450元，B账户一定是350元。

1.1.3、隔离性（I）

所谓的隔离性就是说，事务与事务之间不会互相影响，一个事务的中间状态不会被其他事务感知。

1.1.4、持久性（D）

所谓的持久性，就是说一单事务完成了，那么事务对数据所做的变更就完全保存在了数据库中，即使发生停电，系统宕机也是如此。

2、分布式事务的产生的原因

2.1、数据库分库分表

当数据库单表一年产生的数据超过1000W，那么就要考虑分库分表，具体分库分表的原理在此不做解释，简单的说就是原来的一个数据库变成了多个数据库。这时候，如果一个操作既访问01库，又访问02库，而且要保证数据的一致性，那么就要用到分布式事务。

2.2、应用SOA化

所谓的SOA化，就是业务的服务化。比如原来单机支撑了整个电商网站，现在对整个网站进行拆解，分离出了订单中心、用户中心、库存中心。对于订单中心，有专门的数据库存储订单信息，用户中心也有专门的数据库存储用户信息，库存中心也会有专门的数据库存储库存信息。这时候如果要同时对订单和库存进行操作，那么就会涉及到订单数据库和库存数据库，为了保证数据一致性，就需要用到分布式事务。

以上两种情况表象不同，但是本质相同，都是因为要操作的数据库变多了！

3、分布式事务的应用场景

3.1、支付

最经典的场景就是支付了，一笔支付，是对买家账户进行扣款，同时对卖家账户进行加钱，这些操作必须在一个事务里执行，要么全部成功，要么全部失败。而对于买家账户属于买家中心，对应的是买家数据库，而卖家账户属于卖家中心，对应的是卖家数据库，对不同数据库的操作必然需要引入分布式事务。

3.2、在线下单

买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

其他的还有金融系统中的银行卡充值（银行系统和金融系统）、教育系统中下单选课业务（订单系统和选课系统），可见，分布式事务的应用场景还是应用于多个系统来完成一个操作。

4、分布式理论

4.1、CAP定理

分布式理论有很多，这里说一下分布式理论基础-CAP定理。了解了CAP理论有助于我们研究分布式事务的处理方案。

CAP定理是由加州大学伯克利Eric Brewer教授提出来的，在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：

• 一致性（Consistence） :所有节点访问同一份最新的数据副本
• 可用性（Availability）:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
• 分区容错性（Partition tolerance） : 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

通过下图再来理解一下CAP理论：

• 一致性(Consistency)：服务A、B、C三个结点都存储了用户数据， 三个结点的数据需要保持同一时刻数据一致性。
• 可用性(Availability)：服务A、B、C三个结点，其中一个结点宕机不影响整个集群对外提供服务，如果只有服务A结点，当服务A宕机整个系统将无法提供服务，增加服务B、C是为了保证系统的可用性。
• 分区容忍性(Partition Tolerance)：分区容忍性就是允许系统通过网络协同工作，分区容忍性要解决由于网络分区导致数据的不完整及无法访问等问题。在存在网络分区的情况下，仍然可以接受请求（满足一致性和可用性)。（分布式系统不可避免的出现了多个系统通过网络协同工作的场景，结点之间难免会出现网络中断、网延延迟等现象，这种现象一旦出现就导致数据被分散在不同的结点上，这就是网络分区）

CAP仅适用于原子读写的NOSQL场景中，并不适合数据库系统。

4.1.1、分布式系统能否兼顾C、A、P？

在保证分区容忍性的前提下一致性和可用性无法兼顾，如果要提高系统的可用性就要增加多个结点，如果要保证数据的一致性就要实现每个结点的数据一致，结点越多可用性越好，但是数据一致性越差。所以，在进行分布式系统设计时，同时满足“一致性”、“可用性”和“分区容忍性”三者是几乎不可能的

4.1.2、CAP有哪些组合方式？

• CA：放弃分区容忍性，加强一致性和可用性，关系数据库按照CA进行设计。
• AP：放弃一致性，加强可用性和分区容忍性，追求最终一致性，很多NoSQL数据库按照AP进行设计。
  说明：这里放弃一致性是指放弃强一致性，强一致性就是写入成功立刻要查询出最新数据。追求最终一致性是指允许暂时的数据不一致，只要最终在用户接受的时间内数据 一致即可
• CP：放弃可用性，加强一致性和分区容忍性，一些强一致性要求的系统按CP进行设计，比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。（ 说明：由于网络问题的存在，CP系统可能会出现待等待超时，如果没有处理超时问题，则整个系统会出现阻塞）

总结： 在分布式系统设计中AP的应用较多，即保证分区容忍性和可用性，牺牲数据的强一致性（写操作后立刻读取到最新数据），保证数据最终一致性。比如：订单退款，今日退款成功，明日账户到账，只要在预定的用户可以接受的时间内退款事务走完即可。

4.1.3、注意：不是所谓的3选2（不要被网上大多数文章误导了）:

大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在CAP理论诞生12年之后，CAP之父也在2012年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1。也就是说当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

如果想深入学习一下CAP看一下这篇文章吧，《分布式系统之CAP理论》 ：https://blog.csdn.net/wang_luwei/article/details/120372660

4.2、BASE理论

BASE理论由eBay架构师Dan Pritchett提出，在2008年上被分表为论文，并且eBay给出了他们在实践中总结的基于BASE理论的一套新的分布式事务解决方案。

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。

4.2.1、BASE理论的核心思想

即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

针对数据库领域，BASE思想的主要实现是对业务数据进行拆分，让不同的数据分布在不同的机器上，以提升系统的可用性，当前主要有以下两种做法：

• 按功能划分数据库
• 分片（如开源的Mycat、Amoeba等）。

由于拆分后会涉及分布式事务问题，所以eBay在该BASE论文中提到了如何用最终一致性的思路来实现高性能的分布式事务。

4.2.2、BASE理论三要素

1. 基本可用

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

比如：

• 响应时间上的损失:正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
• 系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2. 软状态

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

3. 最终一致性

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

5、常见的分布式事务解决方案

5.1、基于XA协议的两阶段提交（2pc）

XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器（协调者）和本地资源管理器（参与者）。其中本地资源管理器（参与者）往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器（协调者）作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：

两阶段提交（Two-phase Commit，2PC），通过引入协调者（Coordinator）来协调参与者的行为，并最终决定这些参与者是否要真正执行事务。两个阶段过程如下：

• 第一阶段：准备阶段：协调者询问参与者事务是否执行成功，参与者发回事务执行结果。

• 第二阶段：提交阶段：如果事务在每个参与者上都执行成功，事务协调者发送通知让参与者提交事务；否则，协调者发送通知让参与者回滚事务。

需要注意的是，在准备阶段，参与者执行了事务，但是还未提交。只有在提交阶段接收到协调者发来的通知后，才进行提交或者回滚。

• 2PC的优点：实现强一致性，部分关系数据库支持（Oracle、MySQL等）。

• 缺点：整个事务的执行需要由协调者在多个节点之间去协调，增加了事务的执行时间，性能低下。

5.1.1、 存在的问题：

• 同步阻塞 ：所有事务参与者在等待其它参与者响应的时候都处于同步阻塞状态，无法进行其它操作。

• 单点问题 ：协调者在 2PC 中起到非常大的作用，发生故障将会造成很大影响。特别是在阶段二发生故障，所有参与者会一直等待状态，无法完成其它操作。

• 数据不一致 ：在阶段二，如果协调者只发送了部分 Commit 消息，此时网络发生异常，那么只有部分参与者接收到 Commit 消息，也就是说只有部分参与者提交了事务，使得系统数据不一致。

• 太过保守 ：任意一个节点失败就会导致整个事务失败，没有完善的容错机制。

总的来说，XA协议比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。但是，XA也有致命的缺点，那就是性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。XA目前在商业数据库支持的比较理想，在mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。

5.2、MQ消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：

过程如下：

• 1、A系统向消息中间件发送一条预备消息
• 2、消息中间件保存预备消息并返回成功
• 3、A执行本地事务
• 4、A发送提交消息给消息中间件

通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：

• 步骤一出错，则整个事务失败，不会执行A的本地操作

• 步骤二出错，则整个事务失败，不会执行A的本地操作

• 步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息

• 步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务

基于消息中间件的两阶段提交往往用在高并发场景下，将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作，其中B系统的操作由消息驱动，只要消息事务成功，那么A操作一定成功，消息也一定发出来了，这时候B会收到消息去执行本地操作，如果本地操作失败，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。原理如下：

虽然上面的方案能够完成A和B的操作，但是A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。当然，这种玩法也是有风险的，如果B一直执行不成功，那么一致性会被破坏，具体要不要玩，还是得看业务能够承担多少风险。

5.2.1、第二种解释

对比上面第一种解释，来看看第二种解释。

有一些第三方的MQ是支持事务消息的，比如RocketMQ，他们支持事务消息的方式也是类似于采用的二阶段提交，但是市面上一些主流的MQ都是不支持事务消息的，比如 RabbitMQ 和 Kafka 都不支持。

以阿里的 RocketMQ 中间件为例，其思路大致为：

• 第一阶段Prepared消息，会拿到消息的地址。

• 第二阶段执行本地事务，

• 第三阶段通过第一阶段拿到的地址去访问消息，并修改状态。

也就是说在业务方法内要想消息队列提交两次请求，一次发送消息和一次确认消息。如果确认消息发送失败了RocketMQ会定期扫描消息集群中的事务消息，这时候发现了Prepared消息，它会向消息发送者确认，所以生产方需要实现一个check接口，RocketMQ会根据发送端设置的策略来决定是回滚还是继续发送确认消息。这样就保证了消息发送与本地事务同时成功或同时失败。

• 优点： 实现了最终一致性，不需要依赖本地数据库事务。

• 缺点： 实现难度大，主流MQ不支持，RocketMQ事务消息部分代码也未开源。

5.3、补偿事务（TCC）

TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段：

• Try 阶段主要是对业务系统做检测及资源预留
• Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。
• Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

举个例子，假入 Bob 要向 Smith 转账，思路大概是： 我们有一个本地方法，里面依次调用

1. 首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。
2. 在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。
3. 如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些

缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。

简单如下：

所谓的TCC编程模式，也是两阶段提交的一个变种。TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。

5.4、本地消息表（异步确保）

本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。

1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
2. 之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
3. 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

• 优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。

• 缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

6、总结

分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。作为技术人员，一定不能忘了技术是为业务服务的，不要为了技术而技术，针对不同业务进行技术选型也是一种很重要的能力。

以上是一些关于分布式事务的简单总结。