蚂蚁金服大规模事务实战和开源历程

分布式事务难题下的蚂蚁金服大规模事务演进与开源探索

序言

随着互联网技术的飞速更迭，分布式架构已经成为了当今服务架构设计和开发的首选方案。而分布式架构带来的一个重大挑战就是分布式事务的一致性难题，事务的原子性、一致性、隔离性和持久性如何在一个分布式架构中得以保证，成为了一个严峻的技术挑战。

蚂蚁金服大规模事务实战历程

蚂蚁金服作为一个拥有海量交易的互联网金融巨头，从创立之初就面临着严峻的分布式事务挑战。蚂蚁金服业务从单库单表到分库分表，再到分布式事务，经历了一段漫长的演变历程。

1、单库单表的局限

初期，蚂蚁金服的业务还相对集中，数据量也较少，单库单表方案可以满足需求。但随着业务的飞速增长，数据量也呈指数级增长，单库单表方案的瓶颈日益凸显，表结构过于复杂、单表数据量过大、写入性能瓶颈、表扫描性能瓶颈、数据库死锁高发等问题接踵而至。

2、水平拆分分库分表

针对单库单表的局限，蚂蚁金服提出了“水平拆分分库分表”的拆库分表方案。该方案将数据按特定规则拆分到不同的库表中，解决了单表数据量过大问题，也提升了数据库的并发写入性能和表扫描性能，但同时也给分布式事务带来了严峻挑战。

3、分布式事务难题

分库分表后，原来在单库单表中理所应当的事务一致性问题，演变成了复杂棘手的分布式事务难题。

①  并发事务下跨库并发写入数据一致性保障难题。
②  并发事务下跨库数据转移引发数据完整性问题。
③  并发事务下跨库数据引用导致数据脏读问题。

传统的基于两阶段提交协议的分布式事务方案，其强一致性和单点事务模型难以满足蚂蚁金服海量交易场景下的高并发和低延时需求。

蚂蚁金服分布式事务演进

1、TCC 两阶段提交方案

针对分布式事务难题，蚂蚁金服研发团队率先提出了基于 TCC（Try-Comfirm-Cancel）模型的两阶段提交方案。TCC 方案将一个复杂的事务拆分成三个阶段：Try、Comfirm、Cancel。

Try 阶段：事务参与方先尝试扣减业务资源，并做好资源恢复的能力。
Comfirm 阶段：所有事务参与方都 Try 成功后，再提交资源确认，并释放资源占有。
Cancel 阶段：如果 Comfirm 阶段部分事务参与方提交资源确认异常，则对未提交的事务参与方逐个进行回滚。

2、柔性分布式事务 Seata

为进一步提升分布式事务的一致性和可靠性，蚂蚁金服分布式中间件团队又推出一项 Seata（Simple, Easy, and Automatic Transaction for Ali applications）开源分布式事务中间件。Seata 采用了柔性分布式事务模型，该模型扩展了 TCC 两阶段提交协议，并引入回查补偿等一系列手段，大幅提升了事务的最终一致性保障，并降低了对业务方的侵入性。

3、基于 Seata 的分布式事务最佳实战

• 确保业务的幂等性。业务方在进行分布式事务开发时，需要确保业务具备幂等性，即无论事务运行多次，其产生的最终数据一致性都是一致的。
• 合理使用事务隔离级别。在高并发场景下，合理使用数据库的事务隔离级别至关，可以权衡事务一致性和并发吞吐量之间的度。
• 对 Seata 的合理调优。Seata 的部分策略化接口提供了大量黑盒化接口，业务方在使用 Seata 开发分布式事务时，可以通过合理调优 Seata 的策略化接口，以降低分布式事务对业务的影响。

结束语

分布式事务是分布式架构中至关重要的一个环节，蚂蚁金服从单库单表到分库分表，再到分布式事务，经历了一段漫长的演变历程。在分布式事务的探索和沉淀中，蚂蚁金服团队不断创新，开源分布式事务中间件 Seata 的诞生，进一步推动了分布式事务的演进和普及，也为业界带来了宝贵的经验和启发。