蚂蚁金服分布式事务框架

Bertha 。 2022-03-21 07:45 303阅读 0赞

# 分布式事务 #

### 基本术语 ###

<table> 
 <thead> 
  <tr> 
   <th align="left">术语</th> 
   <th align="right">描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="left">事务</td> 
   <td align="right">事务是指作为单个逻辑工作单元执行的一系列操作，要么完全执行，要么完全不执行。</td> 
  </tr> 
  <tr> 
   <td align="left">分布式事务</td> 
   <td align="right">事务的发起者、资源及资源管理器和事务协调者分别位于不同的分布式系统的不同节点之上。</td> 
  </tr> 
  <tr> 
   <td align="left">分支事务</td> 
   <td align="right">一个分布式事务可能包含多个数据库本地事务，在分布式事务框架下，分支事务可能是一个分库上执行的 SQL 语句，或是一个自定义模式服务的调用。</td> 
  </tr> 
  <tr> 
   <td align="left">发起方</td> 
   <td align="right">分布式事务的发起方负责启动分布式事务，通过调用参与者的服务，将参与者纳入到分布式事务当中，并决定整个分布式事务是提交还是回滚。一个分布式事务有且只能有一个发起方。</td> 
  </tr> 
  <tr> 
   <td align="left">参与者</td> 
   <td align="right">参与者提供分支事务服务。当一个参与者被发起方调用，则被纳入到该发起方启动的分布式事务中，成为该分布式事务的一个分支事务。一个分布式事务可以有多个参与者。</td> 
  </tr> 
  <tr> 
   <td align="left">事务管理器</td> 
   <td align="right">事务管理器是一个独立的服务，用于协调分布式事务，包括创建主事务记录、分支事务记录，并根据分布式事务的状态，调用参与者提交或回滚方法。</td> 
  </tr> 
  <tr> 
   <td align="left">主事务记录</td> 
   <td align="right">又叫 Activity 记录，是整个分布式事务的主体。其最核心的数据结构是事务号（TX_ID）和事务状态（STATE），它是在启动分布式事务时持久化写入数据库的，它的状态决定了这个分布式事务的状态。</td> 
  </tr> 
  <tr> 
   <td align="left">分支事务记录</td> 
   <td align="right">又叫 Action 记录，用于标识分支事务。它记录了该提供该分支事务的参与者的信息，其中包括参与者的唯一标识等。通过分支事务信息，事务管理器就可以对参与者进行提交或者回滚操作。</td> 
  </tr> 
  <tr> 
   <td align="left">最终一致</td> 
   <td align="right">事务处理过程中，会有短暂不一致的情况，但通过恢复系统，可以让事务的数据达到最终一致的目标。</td> 
  </tr> 
 </tbody> 
</table>

### 解决问题 ###

分布式事务解决三大核心问题：**跨数据库**、**跨服务**以及**混合分布式事务**。

#### 跨数据库分布式事务 ####

当业务规模增大，单库单表无法满足业务需求时，自然就会出现分库分表的情况。但是，单机事务又不能保证分库后的事务属性，分布式事务几乎无法避免。分布式事务可以让应用轻松具备跨库分布式事务处理能力，像使用单机数据库事务一样，透明地使用分布式事务。

#### 跨服务的分布式事务 ####

在基于 SOA（Service-Oriented Architecture，面向服务架构）的分布式应用环境下，系统按照功能解耦，拆分成不同的微服务，一项业务往往会涉及多个服务之间的调用。因此，为了保障业务完整，需要保证各调用服务间的数据一致性。分布式事务同样支持跨服务的分布式事务，并且可以很方便的与 SOFABoot、Spring Cloud、Dubbo 等框架打通，实现业务链路级别的分布式事务。

#### 混合分布式事务 ####

在一个大规模的分布式应用环境下，除了常见的微服务、数据库资源之外，还会涉及到消息队列、缓存等系统资源的使用。同时，依然需要保证这些资源间访问的数据的一致性。分布式事务支持在同一个分布式事务中引入数据库、服务、消息队列等不同类型的资源，并且支持混合接入模式。

### 角色简介 ###

分布式事务主要涉及三个角色，发起方、参与者与事务管理器，具体描述如下：

*  发起方：分布式事务的发起方负责启动分布式事务，通过调用参与者的服务，将参与者纳入到分布式事务当中，并决定整个分布式事务是提交还是回滚。一个分布式事务有且只能有一个发起方。
 *  参与者：参与者提供分支事务服务。当一个参与者被发起方调用后，该参与者会被纳入到该发起方启动的分布式事务中，成为该分布式事务的一个分支事务。一个分布式事务可以有多个参与者。
 *  事务管理器：事务管理器是一个独立的服务，用于协调分布式事务，包括创建主事务记录、分支事务记录，并根据分布式事务的状态，调用参与者提交或回滚方法。

### 事务执行状态说明 ###

分布式事务使用两阶段提交协议（Two-Phase Commit Protocol，简称 2PC）来保证事务执行的原子性。2PC 包含两个阶段：

第一阶段，也称准备阶段。由事务发起者向各参与者发送请求，询问参与者是否准备好执行事务。  
第二阶段，也称提交阶段。在一阶段所有参与者都确认可以执行事务后，各参与者开始分别执行事务分支。所有分支都成功则事务数据提交成功，否则，所有分支都进行数据回滚操作。  
事务在某一时间点可能处在以下状态之一：

*  初始化：应用发起事务
 *  进行中
    
     *  准备中：一阶段操作中
     *  提交中：一阶段结束，正在二阶段的提交操作中
     *  回滚中：一阶段结束，因为某些业务失败，正在二阶段的回滚操作中
 *  已结束
    
     *  已提交：事务结束，事务执行的数据变更已提交
     *  已回滚：事务结束，事务执行的数据变更已回滚
 *  异常
    
     *  提交异常：一阶段结束，二阶段处理提交操作时出现异常
     *  回滚异常：一阶段结束，二阶段处理回滚操作时出现异常
     *  回查异常：一阶段结束，二阶段处理回查业务接口时出现异常

### 分布式事务中的二阶段提交是什么？ ###

> 二阶段提交协议（Two-phase Commit Protocol，简称 2PC）是分布式事务的核心协议。在此协议中，一个事务管理器（Transaction Manager，简称 TM）协调 1 个或多个资源管理器（Resource Manager，简称 RM）的活动，所有资源管理器向事务管理器汇报自身活动状态，由事务管理器根据各资源管理器汇报的状态（完成准备或准备失败）来决定各资源管理器是“提交”事务还是进行“回滚”操作。

二阶段提交的具体流程如下：

1.  应用程序向事务管理器提交请求，发起分布式事务；
2.  在第一阶段，事务管理器联络所有资源管理器，通知它们准备提交事务；
3.  各资源管理器返回完成准备（或准备失败）的消息给事务管理器（响应超时算作失败）；
4.  在第二阶段：

*  如果所有资源管理器均完成准备（如图 1），则事务管理器会通知所有资源管理器执行事务提交；
 *  如果任一资源管理器准备失败（如图 2 中的资源管理器 B），则事务管理器会通知所有资源管理器进行事务回滚。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXdveW9uemhl_size_16_color_FFFFFF_t_70]

### 分布式事务中的 TCC 模型 ###

Try-Confirm-Cancel（TCC）是初步操作（Try）、确认操作（Confirm）和取消操作（Cancel）三种操作的缩写，这三种操作的业务含义如下：

1.  Try 阶段：对业务系统做检测及资源预留；
2.  Confirm 阶段：对业务系统做确认提交。默认 Confirm 阶段是不会出错的，只要 Try 成功，Confirm 一定成功；
3.  Cancel 阶段：当业务执行出现错误，需要回滚的状态下，执行业务取消，释放预留资源。

TCC 是二阶段提交协议（Two-phase Commit Protocol，简称 2PC）的扩展，Try 操作对应 2PC 中一阶段的准备提交事务（Prepare），Confirm 对应 2PC 中二阶段事务提交（Commit），Cancel 对应 2PC 中二阶段事务回滚（Rollback）。

与 2PC 不同的是，TCC 是一种编程模型，是应用层的 2PC；TCC 的 3 个操作均由编码实现，通过编码实现了 2PC 资源管理器的功能。

TCC 自编码的特性决定 TCC 资源管理器可以跨数据库、跨应用实现资源管理，将对不同的数据库访问、不同的业务操作通过编码方式转换一个原子操作，解决了复杂业务场景下的事务问题。同时 TCC 的每一个操作对于数据库来讲都是一个本地数据库事务，操作结束则本地数据库事务结束，数据库的资源也就被释放；这就规避了数据库层面的 2PC 对资源占用导致的性能低下问题。

### 柔性事务的定义与分类 ###

#### 柔性事务的定义 ####

**刚性事务**（如单数据库）完全遵循 ACID 规范，即数据库事务正确执行的四个基本要素：

*  原子性（Atomicity）
 *  一致性（Consistency）
 *  隔离性（Isolation）
 *  持久性（Durability）

**柔性事务**（如分布式事务）为了满足可用性、性能与降级服务的需要，降低一致性（Consistency）与隔离性（Isolation）的要求，遵循 BASE 理论：

*  基本业务可用性（Basic Availability）
 *  柔性状态（Soft state）
 *  最终一致性（Eventual consistency）

同样的，柔性事务也部分遵循 ACID 规范：  
原子性：严格遵循  
一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽  
隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽  
持久性：严格遵循

#### 柔性事务的分类 ####

柔性事务分为：两阶段型、补偿型、异步确保型、最大努力通知型。

1.  两阶段型  
    分布式事务二阶段提交，对应技术上的 XA、JTA/JTS，这是分布式环境下事务处理的典型模式。
2.  补偿型  
    TCC 型事务（Try-Confirm-Cancel）可以归为补偿型。在 Try 成功的情况下，如果事务要回滚，Cancel 将作为一个补偿机制，回滚 Try 操作；TCC 各操作事务本地化，且尽早提交（没有两阶段约束）；当全局事务要求回滚时，通过另一个本地事务实现“补偿”行为。  
    TCC 是将资源层的二阶段提交协议转换到业务层，成为业务模型中的一部分。
3.  异步确保型  
    将一些有同步冲突的事务操作变为异步操作，避免对数据库事务的争用，如消息事务机制。
4.  最大努力通知型  
    通过通知服务器（消息通知）进行，允许失败，有补充机制。

### 问题 ###

1.  有没有可能在回滚时已经时过境迁，回滚前该记录已经发生了很多次改变，那么如何应对？  
    在update之前，会先把账户的金额保存下来，执行update操作，然后把执行之后的金额保存下来。因为在二阶段有可能会是回滚操作，回滚的时候如果想把执行之前的数据覆盖回去的话，必须要保证在覆盖的那个时刻，这些行上面的数据没有被别人变更过，所以最后会加一个逻辑行锁，这个就是金融系统的特性需求。

### 参考资料 ###

[XTS支付宝分布式事务学习指南][XTS]  
[大规模SOA系统中的分布式事务处理\_程立\_SD2C2008][SOA_SD2C2008]  
[支付宝运营架构中柔性事务指的是什么？][Link 1]  
[分布式事务：蚂蚁金服核心金融场景下的演进][Link 2]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXdveW9uemhl_size_16_color_FFFFFF_t_70]: /images/20220321/03af6b8d4d4c4e719c4cabaad791db3f.png
[XTS]: http://wwyz-study.oss-cn-hangzhou.aliyuncs.com/XTS%20%E6%94%AF%E4%BB%98%E5%AE%9D%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1%E5%AD%A6%E4%B9%A0%E6%8C%87%E5%8D%97.pdf
[SOA_SD2C2008]: http://wwyz-study.oss-cn-hangzhou.aliyuncs.com/%E5%A4%A7%E8%A7%84%E6%A8%A1SOA%E7%B3%BB%E7%BB%9F%E4%B8%AD%E7%9A%84%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1%E5%A4%84%E7%90%86_%E7%A8%8B%E7%AB%8B_SD2C2008.pdf
[Link 1]: https://www.zhihu.com/question/31813039
[Link 2]: http://tech.it168.com/a2018/0523/3204/000003204767.shtml