分布式事务详解

1. 分布式事务理论

1.1 CAP(强一致性)

CAP 定理，又被叫作布鲁尔定理，理论含义是，一个分布式系统不可能同时满足一致性(C:Consistency)，可用性(A: Availability)和分区容错 性(P:Partition tolerance)这三个基本需求，最多只能同时满足其中的2个。

选项	描述
C 一致性	分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致
A 可用性	Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常
P 分区容错性	系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务

1.2 BASE(最终一致性)

BASE 是指基本可用(Basically Available)、软状态( Soft State)、最终一致性( Eventual Consistency)。它的核心思想是即使无法做到强一致性(CAP 就是强一致性)，但应用可以采用 适合的方式达到最终一致性。

• BA指的是基本业务可用性，支持分区失败;
• S表示柔性状态，也就是允许短时间内不同步;
• E表示最终一致性，数据最终是一致的，但是实时是不一致的。

原子性和持久性必须从根本上保障，为了可用性、性能和服务降级的需要，只有降低一致性和隔离 性的要求。BASE 解决了 CAP 理论中没有考虑到的网络延迟问题，在BASE中用软状态和最终一 致，保证了延迟后的一致性。

2. 分布式事务模式

了解了分布式事务中的强一致性和最终一致性理论，下面介绍几种常见的分布式事务的解决方案。

2.1 2PC模式(强一致性)

2PC是Two-Phase Commit缩写，即两阶段提交，就是将事务的提交过程分为两个阶段来进行处理。事务的发起者称协调者，事务的执行者称参与者。协调者统一协调参与者执行。

• 阶段 1:准备阶段
  协调者向所有参与者发送事务内容，询问是否可以提交事务，并等待所有参与者答复。 各参与者执行事务操作，但不提交事务，将 undo 和 redo 信息记入事务日志中。 如参与者执行成功，给协调者反馈 yes;如执行失败，给协调者反馈 no。
• 阶段 2:提交阶段
  如果协调者收到了参与者的失败消息或者超时，直接给每个参与者发送回滚(rollback)消息;
  否则，发送提交(commit)消息。

2PC 方案实现起来简单，实际项目中使用比较少，主要因为以下问题:

• 性能问题:所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶 颈。
• 可靠性问题:如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定 状态。
• 数据一致性问题:在阶段 2 中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。

2.2 3PC模式(强一致性)

3PC 三阶段提交，是两阶段提交的改进版本，与两阶段提交不同的是，引入超时机制。同时在协 调者和参与者中都引入超时机制。三阶段提交将两阶段的准备阶段拆分为 2 个阶段，插入了一个 preCommit 阶段，解决了原先在两阶段提交中，参与者在准备之后，由于协调者或参与者发生崩 溃或错误，而导致参与者无法知晓处于长时间等待的问题。如果在指定的时间内协调者没有收到参 与者的消息则默认失败。

• 阶段1:canCommit
  协调者向参与者发送 commit 请求，参与者如果可以提交就返回 yes 响应，否则返回 no 响应。
• 阶段2:preCommit
  协调者根据阶段 1 canCommit 参与者的反应情况执行预提交事务或中断事务操作。
  • 参与者均反馈 yes:协调者向所有参与者发出 preCommit 请求，参与者收到 preCommit 请求后，执行事务操作，但不提交;将 undo 和 redo 信息记入事务日志 中;各参与者向协调者反馈 ack 响应或 no 响应，并等待最终指令。
  • 任何一个参与者反馈 no或等待超时:协调者向所有参与者发出 abort 请求，无论收到 协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事 务。
• 阶段3:do Commit
  该阶段进行真正的事务提交，根据阶段 2 preCommit反馈的结果完成事务提交或中断操作。

相比2PC模式，3PC模式降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段 3 中协调者出现问题时(比如网络中断等)，参与者会继续提交事务。

2.3 XA(强一致性)

XA是由X/Open组织提出的分布式事务的规范，是基于两阶段提交协议。 XA规范主要定义了全局 事务管理器™和局部资源管理器(RM)之间的接口。目前主流的关系型数据库产品都是实现 了XA接口。

XA之所以需要引入事务管理器，是因为在分布式系统中，从理论上讲两台机器理论上无法达到一 致的状态，需要引入一个单点进行协调。由全局事务管理器管理和协调的事务，可以跨越多个资源 (数据库)和进程。

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

3.4 TCC模式(最终一致性)

TCC(Try-Confirm-Cancel)的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。TCC 是服务化的两阶段 编程模型，其 Try、Confirm、Cancel 3 个方法均由业务编码实现:

• Try 操作作为一阶段，负责资源的检查和预留;
• Confirm 操作作为二阶段提交操作，执行真正的业务;
• Cancel 是预留资源的取消;

TCC事务模式相对于 XA 等传统模型如下图所示:

TCC 模式相比于 XA，解决了如下几个缺点:

• 解决了协调者单点，由主业务方发起并完成这个业务活动。业务活动管理器可以变成多点， 引入集群。
• 同步阻塞:引入超时机制，超时后进行补偿，并且不会锁定整个资源，将资源转换为业务逻 辑形式，粒度变小。
• 数据一致性，有了补偿机制之后，由业务活动管理器控制一致性。

3.5 消息队列模式(最终一致性)

消息队列的方案最初是由 eBay 提出，基于TCC模式，消息中间件可以基于 Kafka、RocketMQ 等 消息队列。此方案的核心是将分布式事务拆分成本地事务进行处理，将需要分布式处理的任务通过 消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或MQ中间件，再通过业务规 则人工发起重试。

下面描述下事务的处理流程:

• 步骤1:事务主动方处理本地事务。事务主动方在本地事务中处理业务更新操作和MQ写消息操作。
• 步骤 2:事务主动方通过消息中间件，通知事务被动方处理事务通知事务待消息。事务主动方主动写消息到MQ，事务消费方接收并处理MQ中的消息。
• 步骤 3:事务被动方通过MQ中间件，通知事务主动方事务已处理的消息，事务主动方根据反 馈结果提交或回滚事务。

为了数据的一致性，当流程中遇到错误需要重试，容错处理规则如下:

• 当步骤 1 处理出错，事务回滚，相当于什么都没发生。
• 当步骤 2 处理出错，由于未处理的事务消息还是保存在事务发送方，可以重试或撤销本地业 务操作。
• 如果事务被动方消费消息异常，需要不断重试，业务处理逻辑需要保证幂等。
• 如果是事务被动方业务上的处理失败，可以通过MQ通知事务主动方进行补偿或者事务回滚。
• 如果多个事务被动方已经消费消息，事务主动方需要回滚事务时需要通知事务被动方回滚。

3.6 Saga模式(最终一致性)

Saga这个概念源于 1987 年普林斯顿大学的 Hecto 和 Kenneth 发表的一篇数据库论文Sagas ，一 个Saga事务是一个有多个短时事务组成的长时的事务。 在分布式事务场景下，我们把一个Saga分 布式事务看做是一个由多个本地事务组成的事务，每个本地事务都有一个与之对应的补偿事务。在 Saga事务的执行过程中，如果某一步执行出现异常，Saga事务会被终止，同时会调用对应的补偿事务完成相关的恢复操作，这样保证Saga相关的本地事务要么都是执行成功，要么通过补偿恢复 成为事务执行之前的状态。(自动反向补偿机制)。

Saga 事务基本协议如下:

• 每个 Saga 事务由一系列幂等的有序子事务(sub-transaction) Ti 组成。
• 每个 Ti 都有对应的幂等补偿动作 Ci，补偿动作用于撤销 Ti 造成的结果。

Saga是一种补偿模式，它定义了两种补偿策略:

• 向前恢复(forward recovery):对应于上面第一种执行顺序，发生失败进行重试，适用于必须要成功的场景。
• 向后恢复(backward recovery):对应于上面提到的第二种执行顺序，发生错误后撤销掉之前所 有成功的子事务，使得整个 Saga 的执行结果撤销。

Saga 的执行顺序有两种，如上图:

• 事务正常执行完成:T1, T2, T3, …, Tn，例如:减库存(T1)，创建订单(T2)，支付(T3)，依次有序完成整个事务。
• 事务回滚:T1, T2, …, Tj, Cj,…, C2, C1，其中 0 < j < n，例如:减库存(T1)，创建订单(T2)，支付(T3)，支付失败，支付回滚(C3)，订单回滚(C2)，恢复库存(C1)。

3.7 Seata框架

Fescar开源项目，最初愿景是能像本地事务一样控制分布式事务，解决分布式环境下的难题。

Seata(Simple Extensible Autonomous Transaction Architecture)是一套一站式分布式事务解 决方案，是阿里集团和蚂蚁金服联合打造的分布式事务框架。Seata目前的事务模式有AT、TCC、 Saga和XA，默认是AT模式，AT本质上是2PC协议的一种实现。

Seata AT事务模型包含TM(事务管理器)，RM(资源管理器)，TC(事务协调器)。其中TC是一个独立 的服务需要单独部署，TM和RM以jar包的方式同业务应用部署在一起，它们同TC建立长连接，在 整个事务生命周期内，保持RPC通信。

• 全局事务的发起方作为TM，全局事务的参与者作为RM
• TM负责全局事务的begin和commit/rollback
• RM负责分支事务的执行结果上报，并且通过TC的协调进行commit/rollback。

在 Seata 中，AT时分为两个阶段的，第一阶段，就是各个阶段本地提交操作;第二阶段会根据第 一阶段的情况决定是进行全局提交还是全局回滚操作。具体的执行流程如下:

• TM 开启分布式事务，负责全局事务的begin和commit/rollback(TM 向 TC 注册全局事务记 录);
• RM 作为参与者，负责分支事务的执行结果上报，并且通过TC的协调进行 commit/rollback(RM 向 TC 汇报资源准备状态 );
• RM分支事务结束，事务一阶段结束;
• 根据TC 汇总事务信息，由TM发起事务提交或回滚操作;
• TC 通知所有 RM 提交/回滚资源，事务二阶段结束;