常用的 分布式事务 都有哪些？我该用哪个？

分布式的CAP理论应该是人尽皆知了，它描述了一致性（C）、可用性（A）、分区容错性（P）的一系列权衡。很多时候，我们要在一致性和可用性之间权衡，而分布式事务，就是在这个大的前提下，尽可能的达成一致性的要求。

目标很小，问题很大，做法也各有不同。

“如何在微服务中实现分布式事务？”一般在被问到这样的问题时，我都会回答“要尽量避免使用分布式事务”，这也是Martin Fowler所推荐的。但现实总是残酷的，拆分了微服务之后，分布式事务是非常硬核的需求，是绕不开的，我们依然要想办法搞定它。但分布式环境错综复杂，还伴随着网络状况产生的超时，如何让事务达到一致性的状态，难度很大。

分布式事务，由一系列小的子事务组成。这些子事务，同大的分布式事务一样，同样要遵循 ACID 的原则。在一致性这个属性上，根据达到一致性之前所存在的时间，又分为强一致性和最终一致性（BASE）。

注意，对于子事务，这里有个小小的误解。并不是只有和数据库打交道的操作，才叫做事务。在微服务环境下，如果你通过 RPC 调用了另外一个远程接口，并造成了相关数据状态的变化，这个 RPC 接口，也叫做事务。

所以，在分布式事务中，我们把这些子事务涉及到的操作，叫做资源。当操作能正常完成的时候，根本不需要什么额外处理。事务主要处理的是发生异常之后的流程。

下面，我们就来看一下常见的分布式事务解决方案。

1. 一阶段提交（1PC）

先来看一下最简单的事务提交情况。

如果你的业务，只有一个资源需要协调，那么它可以直接提交。比如，你使用了一个数据库，那么就可以直接使用 begin，commit 等指令完成事务提交。

在 Spring 中，通过注解，就可以完成这样的事务。如果发生了嵌套事务，它的实现方式，本质上，是通过 ThreadLocal 向下传递的。所以如果你的应用中有子线程相关的事务需要管理，它办不到。

我们再来看分布式事务。所谓的分布式事务，就是协调 2 个或者多个资源，达到共同提交或者共同失败的效果，也就是分布式的 ACID。

2. 两阶段提交（2PC）

在一阶段提交的概念扩展下，最简单的分布式事务解决方案，就是二阶段提交。二阶段提交不是指有两个参与资源，而是说有两个分布式的协调阶段，它可能有多个资源需要协调。

2.1 重要参与者

1. 协调者（coordinator），也就是我们需要自建事务管理器，通常在真个系统中只有一个

2. 事务参与者（participants），就是指的我们所说的资源，通常情况下会有多个，否则也称不上分布式事务了

2.2 过程

广义上的 2PC（two phase commit），有哪两阶段呢？

1. client 分布式事务发起者

2. commit-request/voting 准备阶段

3. commit/rollback 提交或者回滚

准备阶段，也叫做 voting 阶段。所谓的 voting，就是参与者告知协调者，自己的资源到底是能够提交（代表它准备好了），还是取消本次事务（比如发生异常）。

这个投票比较有意思，只要有一个参与者返回了 false，本次事务就需要终止，然后执行 rollback。只有全票通过，才会正常 commit。协调者将这个结果，周知所有参与者的这个过程，就是二阶段。

二阶段提交其实非常容易理解。你可以把每个参与者的执行，想象成正常的 SQL 更新语句。它们一直挂在那里等待，直到协调者给出确切的 commit 或者 rollback 消息，才会正常往下执行。

2.3 问题

1. 阻塞问题。两阶段提交最大的问题，就是它是一个阻塞的协议，效率低。如果协调器永久失败，一些参与者，将永远无法完成它的事务

2. 单点故障问题。由于协调者在整个环节中有着非常重要的作用，所以一旦它发生了SPOF，整个系统将变的不可用，这是不能忍受的

3. 事务完整性问题。在某些情况下，比如协调者发送 commit 指令后，发生异常，有一部分执行成功了，会造成整个事务不一致。因为能不能提交，第一阶段就决定了，第二阶段只是通知而已，你就是死也要给我提交

4. 并不是所有的资源都支持 2PC（或者 XA）

对于第三点，我们举个例子。比如你的 commit-request 阶段全部返回了 yes，然后协调者发送了 commit 指令。但这时候，有一台服务器 A 宕机了，无法执行这个 commit。这时候，我们的 client 也会收到成功的消息。A 机器重启之后，要有能力来恢复、继续执行 commit 指令，这些都是工程上必须要处理的。

2.4 框架

2PC 也叫做 XA 事务，大多数数据库如 MySQL，都支持 XA 协议。在 Java 中，JTA（不是什么 JPA 哦）是 XA 协议的实现。Spring 也有 JTA 的事务管理器。

• Atomikos、bitronix 实现了 JTA，它们只需要提供 jar 包就可以了。实现了 XA 协议的数据库或者消息队列，已经能够具备了准备、提交、回滚的各种能力

• 使用在 seata 等框架，需要启动一个独立的 seata 服务协调者节点。seata 使用的 AT，借助于外部事务管理器，概念与 XA 类似

3. 三阶段提交（3PC）

相比较二阶段提交，三阶段提交最典型的特点是加入了超时机制。当然，3 阶段证明了它有三个阶段，这个差别更显著。它本质上只是 2PC 的一些改进，所以身上完全充满了 2PC 的影子。

3.1 重要参与者

3PC 和 2PC 是一样的。

3.2 过程

3PC 比 2PC 多了一个步骤，那就是询问阶段。

1. CanCommit 询问阶段

2. PreCommit 准备阶段

3. DoCommit 提交阶段

提交阶段，无非就是发送个 commit 或者 rollback 指令，重要的处理还是在准备阶段，3PC 把它一拆为 2。

注意下面这个对应关系哦，2PC 和 3PC 都有一个准备阶段，但它们的作用是不同的。

3PC					2PCCanCommit			commit-request/votingPreCommit DoCommit 			commit复制代码

3PC 的询问阶段，对应的才是 2PC 的准备阶段，都是 ask 一下参与者是否准备好了，但执行过程会有一些区别。

为什么要这么做？因为 2PC 有效率问题。2PC 的执行过程是阻塞的，一个资源在进入准备阶段之后，必须等待所有的资源准备完毕才能进行下一步，在这个过程中，它们对全局一无所知。

比如，有 ABCDE 等 5 个参与者，E 其实是一个有问题的参与者资源。但 2PC 每次都会执行 ABCD 的预提交，当询问到 E 的时候，发现是有问题的，再依次执行 ABCD 等参与者的 rollback。在这种情况下，ABCD 执行了无用的事务预处理和 rollback，是非常浪费资源的。

3PC 通过拆分这个询问阶段，在确保所有参与者建康良好的情况下，才会发起真正的事务处理，在效率和容错性上更胜一筹。从概率上来讲，由于 commit 之前粒度变小了，commit 阶段出问题的几率就变小，能省下不少事。

另外，3PC 引入了超时机制。在 PreCommit 阶段，如果超时，就认为失败；而在 DoCommit 阶段，如果超时还会继续执行下去。但不论怎样，整个事务并不会一直等待下去。

3.3 问题

3PC 理论上是比较优秀的，还能够避免阻塞问题，但它多了一次网络通信。如果参与者的数量比较多，网络质量比较差的情况下，这个开销非常可观。它的实现也比较复杂，在实际应用中，是不太多的。

3PC 也并不是完美的，因为 PreCommit 阶段和 DoCommit 也并不是原子的，和 2PC 类似，依然存在一致性问题。

4. TCC

TCC 是柔性事务，而上面介绍的都是刚性事务。有时候，一个技术问题，可以通过业务建模来实现。

2PC 和 3PC 在概念上看起来虽然简单，但放在分布式环境中，考虑各种超时和宕机问题，如果考虑的周全，那可真是要了老命。

2PC 的框架还是比较多的，但 3PC 全网找了个遍，发现有名的实现几乎没有。

不要伤心，我们有更容易理解，更加直观的分布式事务。那就是 TCC，2007 年的老古董。

TCC 就是大名鼎鼎的补偿事务，是互联网环境最常用的分布式事务。它的核心思想是：为每一个操作，都准备一个确认动作和相应的补偿动作，一共 3 个方法。

与其靠数据库，不如靠自己的代码！2PC，3PC，都和数据库绑的死死的，TCC 才是码农的最爱（意思就是说，你要多写代码）。

如图，TCC 同样分为三个阶段，但非常的粗暴！

• try 尝试阶段 尝试锁定资源

• confirm 确认阶段 尝试将锁定的资源进行提交

• cancel 取消阶段 其中某个环节执行失败，将发起事务取消动作

看起来这三个阶段，是 2 阶段提交的一种？完全不是。但它们的过程可以比较一下。

TCC					2PCTry					业务逻辑Confirm 			commit-request/voting + commitCancel  			rollback复制代码

从上面可以看出来，2PC 是一种对事务过程的划分，而 TCC 是对正常情况的提交和异常情况的补偿。相对于传统的代码，try 和 confirm 两者加起来，才是真正的业务逻辑。

TCC 是非常容易理解的，但它有一个大的前提，就是这三个动作必须都是幂等的，对业务有一定的要求。拿资金转账来说，try 就是冻结金额；confirm 就是完成扣减；cancel 就是解冻，只要对应的订单号是一直的，多次执行也不会有任何问题。

由于 TCC 事务的发起方，直接在业务节点即可完成，和 TCC 的代码在同一个地方。所以，TCC 并不需要一个额外的协调者和事务处理器，它存放在本地表或者资源中即可。

是的，它也要记录一些信息，哪怕是 HashMap 里，否则它根据啥回滚呢？

4.1 问题

TCC 事务，需要较多的编码，以及正确的 try 和 confirm 划分。由于没有中心协调器，不需要阻塞，TCC 的并发量较高，被互联网业务广泛应用。

团队要有能力设计 TCC 接口，将其拆分成正确的 Try 和 Confirm 阶段，实现业务逻辑的分级。

4.2 框架

ByteTCC、tcc-transaction、seata 等。

5. SAGA

SAGA 也是一个柔性事务。

saga 的历史更久远，要追溯到 1987 年的一篇论文，可以说是瓶旧酒。它主要处理的是长活事务，但它不保证 ACID，只保证最终一致性。

所谓长活事务，可以被分解成交错运行的子事务，它通过消息，来协调一系列的本地子事务，来达到最终的一致性。

我们可以把 SAGA 编排器，想象成一个状态机。每当处理完一条消息，它就能够直到要执行的下一条消息（子事务）。

比如，我们把事务 T，拆分成了 T1，T2，T3，T4。那么我们就必须为这些子事务，提供相应的执行逻辑和补偿逻辑。没错，和 TCC 一样，不过比 TCC 少了一步Try动作，同样要求这些操作是幂等的。

你瞧瞧，其实 SAGA 的概念很好理解，你就按照正常的业务逻辑去执行就行了。只不过如果在任何一步发生了异常，就要把前面所提交的数据全部回滚（补偿）。唯一特殊的是，它通常是通过消息驱动来完成事务运转的。

如果你非要追求它的本质，那就是 SAGA 和 TCC 一样，都是先记录执行轨迹，然后通过不断地重试达到最终状态。

上图是rob vettor所绘制的一个典型的 SAGA 事务拆分图。在图中，黑色的线为正常业务流程，红色的线为补偿业务流程。这是一个简单的电子商务结账流程，整个交易跨了 5 个微服务，可以说是非常大的长事务了。

可以看到，这样的事务流转，靠文字描述已经是不好理解了，所以 SAGA 通常会配备一个流程编辑器，直接来把事务编排的过程可视化。

5.1 问题

那问题就有意思多了。

1. 嵌套问题。SAGA 只允许两层嵌套，因为靠消息流转本来就非常复杂了，嵌套层次深在性能和时序上都不允许

2. 如果你的事务包含很多子事务，那么很有可能在某个阶段就执行失败了。但如果补偿操作也发生问题了呢？极端情况下，需要人工参与。在很多时候，需要记录日志（saga log）来配合完成

3. 由于这些小事务并不是同时提交的，所以在执行的过程中，会产生脏数据，这和数据库的 read uncommited 的概念是一样的

5.2 框架

在《微服务架构设计模式》的第四章中，说明了 SAGA 的具体使用示例，现在网络上的大多数文章都来自于此。但据我所知，使用 SAGA 的互联网公司并不是很多，倒是使用 TCC 的比较多一些（可能是遇到的分布式事务都不是长事务）。

seata 同样提供了 SAGA 的方式，主要使用的是状态机驱动的编排模式。为了支持事务的编排，seata 提供了一个专用的流程编辑器（在线）。

http://seata.io/saga_designer/index.html复制代码

设计完毕之后，就可以导出为 JSON 文件，解析之后可以写入到数据库中。

bytetcc 虽然叫 tcc，它也支持 SAGA。

5.3 SAGA vs TCC

上面也提到，我在平常工作中，用到 TCC 比 SAGA 更多一些，也是由于业务场景确定的。下面简单的对比一下。

1. 开发难度。TCC 的开发难度是比 SAGA 要高的，因为它需要处理 Try 阶段来冻结资源，而 SAGA 是直接执行本地事务

2. 脏读问题。TCC 不存在脏读，因为 try 阶段并不影响数据；SAGA 会在小事务之间，或者 cancel 之间出现脏读

3. 效率问题。TCC 无论成功失败，都需要和参与方交互两次；SAGA 在正常情况下交互一次，异常情况下交互两次，所以效率要高

4. 业务流程。TCC 适合少量的分布式事务流程，否则写起来就是噩梦；SAGA 适合业务流程长，参与方多的业务，或者遗留系统等无法改造成 TCC 的业务

5. 手段。TCC 是通过业务建模手段解决技术问题；SAGA 是通过技术手段解决事务编排

6. 本地消息表

本地消息表的使用场景比较局限，它要靠 MQ 去实现，它解决的是数据库事务和 MQ 之间的事务问题。

如图，有一个分布式事务，在正常落库之后，需要通过 MQ 来协调后续业务的执行。但是，写 DB 和写 MQ，是无法达成一致性的，就需要加入一个本地消息表来缓存发送到 MQ 的状态。下面我来描述一下这个过程。

• 1.1 正常写入数据库

• 1.2 在写入数据库的同时，写入一张本地消息表。这张表，用来记录 MQ 消息处理的状态，可以有发送中和已完成两种状态。由于消息表和正常的业务表在一个 DB 中，所以可以达成本地事务，确保同时完成

• 2 写入消息表成功之后，可以异步发送 MQ 消息，且不用关心投递是否成功

• 3 后续业务订阅 MQ 消息。消费成功之后，将会把执行成功的状态，再通过 MQ 来发送。本地业务订阅这个执行状态，并把消息表中对应的记录状态，改为已完成；如果消费失败，则不做过多处理

• 4 存在一个定时任务，持续扫描本地消息表中，状态为发送中的消息（注意延时），并再次把这些消息发送到 MQ，重复 2 的过程

通过这样的循环，就可以达到本地 DB 和 MQ 消费者状态的一致性，完成最终一致性的分布式事务。

可以看到，我们有重发 MQ 的过程，所以这种模式要求消费者也要实现幂等的功能，避免重复对业务产生影响。

6.1 问题

使用本地消息表方案的系统还是挺多的，但它的弊端也显而易见。

1. 需要开发专用的代码，与业务耦合在一起，无法完成抽象的框架

2. 本地消息表需要写数据库，如果数据库本身的 I/O 已经比较高了，它会增加数据库的压力

7. 最大努力补偿

最大努力补偿，是一种衰减式的补偿机制。

拿个最简单的例子来说吧。如果你是微信支付的接入方，微信支付成功之后，它会将支付结果推送到你指定的接口。

微信支付+你的支付结果处理，就可以算是一个大的分布式事务。涉及到微信的系统还有你的自有系统。

如果你的系统一直处理不成功，那么微信支付就会一直不停的重试。这就叫最大努力补偿，用在系统内和系统间都是可以的。

但也不能无限的重试，重试的间隔通常会随着时间衰减。常用的衰减策略有。

messageDelayLevel = 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h复制代码

上面的公式，意味着如果一直无法处理陈功，将在 1s...，最大 2 小时后重试。如果还不陈功，就只能进入人工处理通道。

最大努力补偿只是一种思想，实际的应用有多种方式。比如，我首先将事务落地到消息队列，然后依靠消息队列的重试机制，来达到最大努力补偿的效果，这些都是可行的方案。

8. 总结

我们在文中，从本地事务谈起，分别聊到了 2PC、3PC、TCC、SAGA、本地消息表、最大努力补偿等，也了解到了各种解决方案的一些应用场景和解决方式。

分布式事务框架，在这些理论基础上，都进行了或多或少的修订，也有不少创新。比如 LCN 框架（lock，confirm，notify），就抽象出了控制方和发起方的概念，感兴趣的可以自行了解。

在互联网公司中，由于高并发量的诉求，在实际应用中，相对于强事务，大家普遍选用软事务进行业务处理。使用最多的，就是 TCC、SAGA、本地消息表等解决方案。SAGA 应对长事务特别拿手，但隔离性稍差；TCC 一直型好并发高，但需要较多编码；本地消息表应用场景有限，耦合业务不能复用。各种解决方案都有它的利弊，一定要结合使用场景进行选择。

在框架方面，阿里的 seata（早些年叫 fescar），已经得到了广泛应用，XA、TCC、SAGA 等模式都支持，如果你需要这方面的功能，可以集成尝试一下。

希望看完本文之后，再次碰到“如何在微服务中实现分布式事务？”这种问题，除了回答“要尽量避免使用分布式事务”，你还可以找到确实可行的解决方案。

作者：小姐姐味道

链接：https://juejin.cn/post/7012425995634343966

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。