详解蚂蚁金服大规模分布式架构下数据一致性实践

近日，数据库领域权威的国际机构国际事务处理性能委员会（TPC）在官网发表了最新的TPC-C基准测试结果。蚂蚁金服自主研发的金融级分布式关系数据库OceanBase以两倍于Oracle（甲骨文）的成绩，打破数据库基准性能测试的世界记录，成为全球数据库演进史的重要里程碑。

对此，业界有不少专家表示，蚂蚁金服作为全球科技行业的顶级独角兽能够在应用软件技术上超越老牌科技公司甲骨文自然是可喜可贺的事情。

在蚂蚁金服内部，另一个同样重量级的自研分布式架构SOFAStack值得被关注。在蚂蚁金服向分布式架构转型过程中，为了解决跨数据库、跨服务的业务数据一致性问题，蚂蚁金服自主研发了分布式事务中间件。

2007 年蚂蚁金服自主研发分布式事务中间件，经历 12 年的严苛业务锤炼，磨砺出了一套自研的、面向金融科技行业的技术体系。今年，蚂蚁金服将多年的技术积累贡献给开源分布式事务 Seata 社区，并持续投入社区共建，希望提供分布式事全场景解决方案。目前 Seata 提供了 AT、TCC、Saga 和 XA 四种模式，每一种模式分别有各自的应用场景，丰富的解决方案帮助用户解决了各类场景的数据一致性问题。

为了方便大家快速理解开源分布式事务Seata的具体解决方案，我们节选了蚂蚁金服高级技术专家张森在今年GIAC大会的演讲内容。

分布式事务 Seata 解决方案

AT 模式

今年 1 月份，Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

AT 模式如何做到对业务的无侵入：

一阶段：

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段提交：

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段回滚：

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

TCC 模式

2019 年 3 月份，Seata 开源了 TCC 模式，该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作；事务发起方在一阶段 执行 Try 方式，在二阶段提交执行 Confirm 方法，二阶段回滚执行 Cancel 方法。

TCC 三个方法描述：

Try：资源的检测和预留；

Confirm：执行的业务操作提交；要求 Try 成功 Confirm 一定要能成功；

Cancel：预留资源释放。

业务模型分 2 阶段设计：

用户接入 TCC ，最重要的是考虑如何将自己的业务模型拆成两阶段来实现。

以“扣钱”场景为例，在接入 TCC 前，对 A 账户的扣钱，只需一条更新账户余额的 SQL 便能完成；但是在接入 TCC 之后，用户就需要考虑如何将原来一步就能完成的扣钱操作，拆成两阶段，实现成三个方法，并且保证一阶段 Try 成功的话 二阶段 Confirm 一定能成功。

如上图所示，Try 方法作为一阶段准备方法，需要做资源的检查和预留。在扣钱场景下，Try 要做的事情是就是检查账户余额是否充足，预留转账资金，预留的方式就是冻结 A 账户的 转账资金。Try 方法执行之后，账号 A 余额虽然还是 100，但是其中 30 元已经被冻结了，不能被其他事务使用。

二阶段 Confirm 方法执行真正的扣钱操作。Confirm 会使用 Try 阶段冻结的资金，执行账号扣款。Confirm 方法执行之后，账号 A 在一阶段中冻结的 30 元已经被扣除，账号 A 余额变成 70 元 。

如果二阶段是回滚的话，就需要在 Cancel 方法内释放一阶段 Try 冻结的 30 元，使账号 A 的回到初始状态，100 元全部可用。

用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。

Saga 模式

Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

XA 模式

XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案，任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。

XA 协议有一系列的指令，分别对应一阶段和二阶段操作。“xa start”和 “xa end”用于开启和结束XA 事务；“xa prepare” 用于预提交 XA 事务，对应一阶段准备；“xa commit”和“xa rollback”用于提交、回滚 XA 事务，对应二阶段提交和回滚。

在 XA 模式下，每一个 XA 事务都是一个事务参与者。分布式事务开启之后，首先在一阶段执行“xa start”、“业务 SQL”、“xa end”和 “xa prepare” 完成 XA 事务的执行和预提交；二阶段如果提交的话就执行 “xa commit”，如果是回滚则执行“xa rollback”。这样便能保证所有 XA 事务都提交或者都回滚。

XA 模式下，用户只需关注自己的“业务 SQL”，Seata 框架会自动生成一阶段、二阶段操作；XA 模式的实现如下：

一阶段：

在 XA 模式的一阶段，Seata 会拦截“业务 SQL”，在“业务 SQL”之前开启 XA 事务（“xa start”），然后执行“业务 SQL”，结束 XA 事务“xa end”，最后预提交 XA 事务（“xa prepare”），这样便完成 “业务 SQL”的准备操作。

二阶段提交：

执行“xa commit”指令，提交 XA 事务，此时“业务 SQL”才算真正的提交至数据库。

二阶段回滚：

执行“xa rollback”指令，回滚 XA 事务，完成“业务 SQL”回滚，释放数据库锁资源。

XA 模式下，用户只需关注“业务 SQL”，Seata 会自动生成一阶段、二阶段提交和二阶段回滚操作。XA 模式和 AT 模式一样是一种对业务无侵入性的解决方案；但与 AT 模式不同的是，XA 模式将快照数据和行锁等通过 XA 指令委托给了数据库来完成，这样 XA 模式实现更加轻量化。

除以上内容外，如果你想了解更多关于蚂蚁金服分布式事务的实践经验及Seata的相关内容，我建议你来北京第八届TOP100Summit（11月14-17日）与张森面对面交流，他将在本次大会上为我们分享《蚂蚁金服大规模分布式架构下数据一致性实践》的话题。

他此前在GIAC上分享的相关话题，不仅备受好评且获得了全场的最高分，我们可以一起来听听部分参会者的评价：

1、很好的介绍了分布式事务，了解了这方面的知识，收获很大

2、基于Seata多种模式讲的很清晰，对分布式有更新的认识

3、了解了分布式事务中间件研发思路，以及几种方案的优缺点，我们拟试用

4、深入了解了Seata的特性和分布式事务的应用，受益匪浅

5、纯干货，具体设计也和盘推出

如上所言，TOP100组委会在案例评选时，会从案例目标、成功要点与背后教训、ROI 分析、案例启示、案例对组织的意义等多个维度进行结构化提炼，帮助大家在互联网时代开放、自由的汲取案例带来的独特价值，转化为所有研发中心可用的促进成长的案例。

与上次演讲不同的是，本次大会他会更详尽的阐述蚂蚁分布式事务中间件的功能特性、实现原理和实践经验：

成功要点

蚂蚁金服内部大量使用了 TCC解决跨服务事务问题，TCC是一种高性能灵活的事务解决方案，支持了蚂蚁金服双十一的高性能需求，支持了异地多活的高可用需求；为了让分布式事务使用更加便捷，我们推出FMT、XA 两种无侵入的事务解决方案；为了满足用户的长事务需求，我们又推出了SAGA 模式。当前蚂蚁金服的分布式事务解决方案主要有TCC、FMT、XA和 SAGA 四种模式，丰富的模式覆盖了分布式事务的各类使用场景。

案例启示

1、了解分布式事务问题产生的背景和基本理论

2、了解蚂蚁分布式事务中间件的功能特性、实现原理和实践经验

3、了解分布式事务开源产品Seata的现状、发展方向