深度 | 为你解读 SOFA-DTX 分布式事务的设计演进路线上篇

Posted 2021-04-25 金融级分布式架构

小蚂蚁说：

在读这篇文章之前，你也许感兴趣的其他背景输入：

《》

《》

《》

《》

我们将分为两篇来详细与大家解读，本篇为上篇。主要讲解 SOFA-DTX 如何满足支付业务的核心需求，保障分布式环境下交易一致性，并且在此之上的严苛的工程优化。

随着互联网技术快速发展，数据规模增大，采用分布式数据库或者跨多个数据库的分布式微服务应用在中大规模企业普遍存在，而由于网络、机器等不可靠因素，数据一致性的问题很容易出现，与可扩展性、高可用容灾等要求并肩成为金融IT架构支撑业务转型升级的最大挑战之一。

在蚂蚁金服核心系统提出微服务化时，曾遇到了非常大的技术难题。首先是在服务拆分以后，面临跨服务的一致性问题；其次，支付宝当时的峰值交易量已经非常高了，在解决一致性问题的同时，还需要兼顾性能。

在当时，业界常用的分布式事务解决方案，通常能够实现跨服务一致性，但在热点数据的处理上，难以满足性能需求。

因此，蚂蚁金服微服务化过程中急需一种即能保证一致性，又能保证高性能的方案。当时经过一系列调研和讨论，最终选择了以 BASE 最终一致性思想为基础，在业务层实现两阶段提交的 TCC 分布式事务解决方案，该方案既能保证跨服务的最终一致，又能通过业务灵活加锁的方式大幅减少资源层加锁时间，高效处理热点问题。

随着蚂蚁金服业务不断丰富，业务逻辑越来越复杂，同时蚂蚁金融云上客户也越来越多，对分布式事务解决方案（简称 DTX，Distributed Transaction-eXtended）也不只是追求极限性能，也对接入便捷性、实时一致性有了要求。

我们将分为上下两篇文章，基于分布式事务在支付宝/蚂蚁金服核心金融场景下的演进路线，分享介绍在各阶段的关键设计考量和发展思路。

 

一. 分布式事务在蚂蚁金服的应用背景

1.1 支付宝 SOA 架构演进

最初的支付宝系统架构非常简单，是一个典型的 Web 系统，交易、支付、账务系统是没有分开的，全部集中在一个大工程里，底层用 DB 存储，Web 服务使用Spring 等框架开发，最上层使用 LB 转发用户流量。

随着代码规模和业务逻辑复杂度的增长，将所有的业务模块放在一个 Web 服务内的缺点日益凸显。因此推动了服务模块化拆分，演进成 SOA 架构，很好地解决了应用的伸缩性问题。

在这个架构中，交易系统、支付系统、账务系统分别独立出来了，它们之间的调用靠 RPC，除了服务模块化拆分，还有数据库的垂直拆分，根据业务系统功能，将数据库拆分为多个，每个系统使用独立的数据库。

 

 

1.2 数据一致性问题

数据垂直拆分后，减少了单库的性能瓶颈，但也带来了数据一致性的问题。如下图所示： 

一笔转账业务需要跨交易、支付、账务三个系统才能完成整个流程，并且要求这三个系统要么一起成功，要么一起失败。如果有的成功，有的失败，就有可能造成数据不一致，那么这个业务行为肯定不会被用户所理解。所以，我们系统面临的问题就是 SOA 架构下的数据一致性。

 

二. 关键设计考量：金融级一致性要求与海量并发处理能力

考虑到在解决一致性问题的同时，还要兼顾海量并发处理能力，蚂蚁金服内部结合BASE 理论的思想，选择在业务层实现 2PC（两阶段事务提交）的方式来解决该问题。

BASE 理论是指 BA（Basic Availability，基本业务可用性）；S（Soft state，柔性状态）；E（Eventual consistency，最终一致性）。该理论认为为了可用性、性能与降级服务的需要，可以适当降低一点一致性的要求，即“基本可用，最终一致”。

一般来讲，在传统的单机数据库或者集中式存储数据库里，对于一致性的要求是实时一致；而对于分布式系统，服务与服务之间已经实现了功能的划分，逻辑的解耦，也就更容易弱化一致性，允许处理过程中，数据的短暂不一致，只需要保证数据最终达到一致。

2.1 分布式金融核心的零差错容忍保证：TCC 模型

如本文开篇所述，蚂蚁金服大部分系统的分布式事务解决方案以BASE最终一致性思想为基础，在业务层实现两阶段提交的 TCC（Try-Confirm-Cancel）分布式事务解决方案，以确保在一致性问题的保障和性能方面达到最佳平衡。

 

TCC 分布式事务模型包括三部分，如下所示

• 主业务服务：主业务服务为整个业务活动的发起方，服务的编排者，负责发起并完成整个业务活动。

• 从业务服务：从业务服务是整个业务活动的参与方，负责提供 TCC 业务操作供主业务服务调用

• 初步操作 Try：完成所有业务检查，预留必须的业务资源。

• 确认操作 Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务有且只能成功一次。

• 取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。

• 业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录维护 TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时调用所有从业务服务的Confirm 操作，在业务活动取消时调用所有从业务服务的Cancel 操作。

2.1.1 TCC 与 XA 对比 --- 并发性优势

TCC 把两阶段拆分成了两个独立的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行。

XA 模型的并发事务

  

TCC 模型的并发事务

 

从上面的对比可以发现，TCC 模型相比 XA 模型进一步减少了资源锁的持有时间。XA 模型下，在 Prepare 阶段是不会把事务1所持有的锁资源释放掉的，如果事务2和事务1争抢同一个资源，事务2必须等事务1结束之后才能使用该资源。

而在 TCC 里，因为事务1在 Try 阶段已经提交了，那么事务2可以获得互斥资源，不必再等待事务1的 Confirm 或 Cancel 阶段执行完。也就是说，事务2的 Try 阶段可以和事务1的 Confirm 或 Cancel 阶段并行执行，从而获得了一个比较大的并发性能提升。

2.2 保证大规模交易下的并发性能：极致性能优化

2010年开始，每年天猫双十一大促的峰值交易量成倍增加，如下图所示：

 

折线上的点代表着每一年的交易峰值（TPS）。前面讲过，每次分布式事务需要协调多个参与方，因此，每年交易峰值乘以一个倍数才是分布式事务框架要协调最终达到一致性状态的峰值分支事务数量。事实上，对分布式事务服务来说，2017年已经达到每秒百万级水平。

回顾历年大促，2013年对支付宝的交易处理是对我们挑战很大的一年，2013年双11提出的峰值目标，按照当时大促准备的计算和存储资源，是无法完成的，怎么办？

只能选择继续优化事务框架，让它尽量少消耗资源，并去获得一个更大的性能提升。我们根据 TCC 模型的特点以及日常开发时积累的经验，针对性能问题，做了以下两类优化。

2.2.1 极致性能优化之同库模式

之前的业务活动管理器是一个单独的服务，每次启动业务活动、登记业务操作、提交或回滚业务活动等操作都需要与业务活动管理器交互，并且交互次数与参与者个数成正相关。

因此，为了追求极限性能，将业务活动管理器的远程存储替换成本地存储，如下所示：

减少了 RPC 的调用，同时还会做一些减少存储次数的优化，从而获得性能收益。

通过这种方式，减少 RPC 调用耗时，大幅降低事务执行时间。同时还针对支付、账务等访问频繁的特殊从业务服务，优化处理过程，不再创建单独的分支事务记录，而是将这个信息与主事务记录合并，在创建主事务记录的同时，记录分支事务，最大程度减少与数据库的交互次数，从而获得更高的性能收益。

下面是同库模式优化前后的时序图对比：

优化前时序图

 

优化后时序图

 

其中，绿色方块表示本地数据库访问。可以发现，优化后减少了：(2+n) 次 PRC 延迟 + 1次数据库访问延迟（n表示参与者个数）。

2.2.2 极致性能优化之异步化

从理论上来说，只要业务允许，事务的第二阶段什么时候执行都可以，因此资源已经被业务锁定，不会有其他事务动用该事务锁定的资源。如下图所示：

这就是 TCC 分布式事务模型的二阶段异步化功能，各从业务服务的第一阶段执行成功以后，主业务服务就可以提交完成，框架会保证正确记录事务状态，然后再由框架异步的执行各从业务服务的第二阶段，从而比较完整的诠释最终一致性。

大促的尖峰时刻是从零点开始的几十秒或一分钟之内，在这个时刻的交易，我们会把二阶段的操作从同步转成异步，在冲高的那一刻，二阶段就停止了，一阶段正常扣款，等着交易零点三十分或者夜里一点开始回落的时候，我们才开始打开二阶段，集中做二阶段的动作。

优化后，Confirm 阶段在空闲时段异步执行：

1. 假设 Confirm 阶段与 Try 阶段耗时相同，单个事务耗时减少50%

2. 数据库资源消耗减少50%

本篇总结

为了满足支付业务的核心需求，保障分布式环境下交易一致性。蚂蚁基于 BASE 思想，在业务层实现了 TCC 模型，并且为了业务发展的需求，优化了其工程实践，实现海量并发处理能力，让它的性能可以达到比业界其它产品高很多的状态。

接着，上层业务系统的复杂、业务种类的丰富等等业务需求向分布式事务提出了更高的要求，我们如何思考和应对的呢？下一篇我们将与大家详谈

了解更多：金融级云原生架构解决方案 SOFA

通过十多年的探索与实践，我们积累了大量的架构设计原则、最佳实践和产品服务案例，并构建了一整套金融级云原生架构解决方案，这套架构叫做 SOFA（Scalable Open Financial Architecture，分布式事务 DTX 亦是其重要的组成部分），源自蚂蚁内部分布式架构实践，是一整套完整的金融级中间件产品技术和演进式架构转型服务体系，已经向国内金融机构开放。

蚂蚁金服期望逐步向社区开放（链接如下）：

https://github.com/alipay

开源 SOFA 体系内的各个组件，帮助大家更加敏捷稳妥地实现金融级云原生架构。我们也非常欢迎来自技术社区和各行业的伙伴能够参与共同探讨、交流和共建，使其更加完善和稳固，满足更多金融级架构转型升级的需求。