本文介绍了蚂蚁金服在分布式事务上，经过多年发展，服务于内外部大量不同业务，沉淀出的一整套包含TCC、FMT、XA模型的分布式事务解决方案。并且在持续对外输出的过程中，进一步打磨产品体验，适应各种严苛的金融级场景和机构需求，比如跨机房跨地域的容灾业务连续性保障能力等。
随着互联网技术快速发展，数据规模增大，采用分布式数据库或者跨多个数据库的分布式微服务应用在中大规模企业普遍存在，而由于网络、机器等不可靠因素，数据一致性的问题很容易出现，
在蚂蚁金服核心系统提出微服务化时，曾遇到了非常大的技术难题。首先是在服务拆分以后，面临跨服务的一致性问题；其次，支付宝当时的峰值交易量已经非常高了，在解决一致性问题的同时，还需要
。在当时，业界常用的分布式事务解决方案，通常能够实现跨服务一致性，但在热点数据的处理上，难以满足性能需求。
BASE最终一致性思想为基础，在业务层实现两阶段提交的TCC分布式事务解决方案，该方案既能跨服务的最终一致，又能通过业务灵活加锁的方式大幅减少资源层加锁时间，高效处理热点问题。随着蚂蚁金服业务不断丰富，业务逻辑越来越复杂，同时蚂蚁金融云上客户也越来越多，对分布式事务解决方案（简称DTX
Distributed Transaction-eXtended）也不只是追求极限性能，也对接入便捷性、实时一致性有了要求。这篇文章将基于分布式事务在支付宝/蚂蚁金服核心金融场景下的演进路线，分享介绍其在各阶段的关键设计考量和发展思路。
DB存储，Web服务使用Spring等框架开发，最上层使用LB转发用户流量。随着代码规模和业务逻辑复杂度的增长，将所有的业务模块放在一个
服务内的缺点日益凸显。因此推动了服务模块化拆分，演进成SOA架构，很好地解决了应用的伸缩性问题。在这个架构中，交易系统、支付系统、账务系统分别出来了，它们之间的调用靠RPC
一笔转账业务需要跨交易、支付、账务三个系统才能完成整个流程，并且要求这三个系统要么一起成功，要么一起失败。如果有的成功，有的失败，就有可能造成数据不一致，那么这个业务行为肯定不会被用户所理解。所以，我们系统面临的问题就是
（Basic Availability，基本业务可用性）；S（Soft state，柔性状态）；E（Eventual consistency，最终一致性）。该理论认为为了可用性、性能与降级服务的需要，可以适当降低一点一致性的要求，即“基本可用，最终一致”。一般来讲，在传统的单机数据库或者集中式存储数据库里，对于一致性的要求是实时一致；而对于分布式系统，服务与服务之间已经实现了功能的划分，逻辑的解耦，也就更容易弱化一致性，允许处理过程中，数据的短暂不一致，只需要数据最终达到一致。
TCC（Try-Confirm-Cancel）分布式事务解决方案，以确保在一致性问题的保障和性能方面达到最佳平衡。TCC分布式事务模型包括三部分，如下所示
主业务服务：主业务服务为整个业务活动的发起方，服务的编排者，负责发起并完成整个业务活动。从业务服务：从业务服务是整个业务活动的参与方，负责提供 TCC 业务操作供主业务服务调用
确认操作 Confirm：真正执行的业务逻辑，不作任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，一笔分布式事务有且只能成功一次。
取消操作 Cancel： Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。
业务活动管理器：业务活动管理器管理控制整个业务活动，包括记录 TCC全局事务的事务状态和每个从业务服务的子事务状态，并在业务活动提交时调用所有从业务服务的Confirm 操作，在业务活动取消时调用所有从业务服务的Cancel 操作。
TCC把两阶段拆分成了两个的阶段，通过资源业务锁定的方式进行关联。资源业务锁定方式的好处在于，既不会阻塞其他事务在第一阶段对于相同资源的继续使用，也不会影响本事务第二阶段的正确执行。
XA模型进一步减少了资源锁的持有时间。XA模型下，在Prepare阶段是不会把事务1所持有的锁资源掉的，如果事务2和事务1争抢同一个资源，事务2必须等事务1结束之后才能使用该资源。而在TCC
1在Try阶段已经提交了，那么事务2可以获得互斥资源，不必再等待事务1的Confirm或Cancel阶段执行完。也就是说，事务2的Try阶段可以和事务1的Confirm或Cancel阶段并行执行，从而获得了一个比较大的并发性能提升。2.2
2013年双11提出的峰值目标，按照当时大促准备的计算和存储资源，是无法完成的，怎么办？只能选择继续优化事务框架，让它尽量少消耗资源，并去获得一个更大的性能提升。我们根据TCC
之前的业务活动管理器是一个单独的服务，每次启动业务活动、登记业务操作、提交或回滚业务活动等操作都需要与业务活动管理器交互，并且交互次数与参与者个数成正相关。
从理论上来说，只要业务允许，事务的第二阶段什么时候执行都可以，因此资源已经被业务锁定，不会有其他事务该事务锁定的资源。如下图所示：
分布式事务模型的二阶段异步化功能，各从业务服务的第一阶段执行成功以后，主业务服务就可以提交完成，框架会正确记录事务状态，然后再由框架异步的执行各从业务服务的第二阶段，从而比较完整的诠释最终一致性。大促的尖峰时刻是从零点开始的几十秒或一分钟之内，在这个时刻的交易，我们会把二阶段的操作从同步转成异步，在冲高的那一刻，二阶段就停止了，一阶段正常扣款，等着交易零点三十分或者夜里一点开始回落的时候，我们才开始打开二阶段，集中做二阶段的动作。
阶段在空闲时段异步执行：假设 Confirm 阶段与 Try 阶段耗时相同，单个事务耗时减少50%数据库资源消耗减少50%
众所周知，蚂蚁金服在近几年除了支付业务以外，还发展出了很多复杂的金融业务，比如财富、保险、银行等。同时，在2014
在这些新的场景下面，分布式事务产品面临新的挑战，客户的性能需求可能不像蚂蚁金服内部要求那么高，而是更关注接入的便利性和通用性，要求简单易用，对业务代码无侵入。因此，分布式事务产品开始全面升级，满足更多客户对云端产品的需求。3.1框架托管
（Framework-managed transactions）模型TCC模型作用于业务层，负责协调从业务服务的最终一致性。所有被纳入到分布式事务的从业务服务，需要为框架提供Try
Confirm、Cancel三个方法，并且需要满足幂等性。由于方法实现和要满足的约束条件都需要业务方提供，这无疑就大大提高了接入门槛。所以我们在TCC模型上继续往前推进发展，提出了FMT模型来解决接入便捷性的问题。FMT分布式事务模型与TCC
、Confirm、Cancel三个方法，而是直接按照JDBC标准，通过托管框架与底层数据库交互，就像使用普通数据源一样。托管框架对业务来说是透明的，主要负责解析SQL语义，自动生成两阶段操作。3.2 FMT模型实现原理
SQL操作就可以了，框架会把业务的本地事务操作作为第一阶段。在第一阶段，框架会拦截用户SQL，解析SQL语义，然后把业务SQL涉及数据执行前后的状态保存下来，即数据快照，这个就相当于在逻辑上完成了数据库内的undo和redo操作。在第二阶段，如果这个事务要提交，那么框架直接把快照数据删除就可以了，因为第一阶段的正常操作已经执行完成。如果该事务要回滚，那么会先校验脏写，根据第一阶段保存的执行后的快照，检查在本事务执行过程中，数据有没有被其他操作修改，如果没有，则把数据执行前的快照拿出来，完成回滚操作。3.3一阶段示例
update操作，然后把执行之后的金额保存下来。因为在二阶段有可能会是回滚操作，回滚的时候如果想把执行之前的数据覆盖回去的话，必须要在覆盖的那个时刻，这些行的数据没有被别人变更过，所以最后会加一个逻辑行锁，这个就是金融系统的特性需求。3.4与数据访问代理集成
我们分析了金融云上的客户发现，如果把业务模型假定成数据最终一致性，那么依然有很多金融客户不得不做出很大的和变更，尤其是原有的业务组织模型和业务逻辑实现。而且这种和调整的工作量是很大的，门槛也常高的。
10-20的时间了，但是在工业界应用的历史和案子都很少。为什么会这样呢？我们认为最重要的一点就是在追求数据实时一致性的同时，性能损失太大了。主要有两个比较方面的性能损失，一个是读和写之间的冲突，另一个是写与写之间的冲突。4.2
B账务转账10块钱。但是A账户和B账户分别在两个数据库分片DB1和DB2上。其操作执行过程如下所以：如上图所示，
的本地子事务已经提交完毕，但是DB2的本地子事务还没提交，这个时候只能读到DB1上子事务执行的内容，读不到DB2上的子事务。也就是说，虽然在单个DB上的本地事务是实时一致的，但是从全局来看，一个全局事务执行过程的中间状态被观察到了，全局实时一致性就被了。但是原生的XA
Snapshot），每个事务或者每条SQL执行时都去获取一次，从而实现不同隔离级别下的全局一致性,如下图所示：在
的本地子事务已经提交完毕，DB2的本地子事务还没提交的中间状态，其他并发事务只能看到该事务执行之前的快照。我们的分布式事务产品同样实现了分布式MVCC
OceanBase深度定制优化并发写，进一步提升产品性能，共同打造实时数据一致性的整体解决方案。传统标准的二阶段提交过程如下：
Commit时落盘，减少Commit过程中涉及到的RPC和落盘的操作，以达到减少用户Commit时间的效果。优化后时序图如下：
操作之后，还有Clear操作，但是在执行Clear时，用户的Commit请求已经返回了，所以并不影响用户的Commit请求延迟。因此，从用户的角度来说，单次Commit操作实际上只需要1次日志延迟、1次事务延迟以及2次RPC延迟。通过以上优化，两阶段提交与普通提交的落盘次数和RPC
总结关于分布式事务服务的关键设计考量，首先为了保障支付业务的核心需求，保障分布式下交易一致性的问题，我们基于BASE
在业务层实现了TCC模型，并且为了业务发展的需求，优化了其工程实践，实现海量并发处理能力，让它的性能可以达到比业界其它产品高很多的状态。其次，因为上层业务系统的复杂、业务种类的丰富等等业务需求，对分布式事务解决方案提出了全新的要求，所以我们
在TCC模型基础上又加入了框架托管（FMT）模型，其简单易用，对业务无侵入的特点，可以较好的解决金融云场景下接入便捷性问题。最后，我们对数据实时一致性、通用性、性能再思考，与自研数据库OceanBase
XA模型，共同打造实时数据一致性的整体分布式事务解决方案。六. 了解更多：金融级云原生架构解决方案SOFA
并构建了一整套金融级云原生架构解决方案，这套架构叫做SOFA（Scalable Open Financial Architecture，分布式事务DTX亦是其重要的组成部分），源自蚂蚁内部分布式架构实践，是一整套完整的金融级中间件产品技术和演进式架构转型服务体系，已经向国内金融机构，提供了完整的金融IT基础架构转型量身打造的技术平台和可落地路径，使业务应用能专注需求作敏捷交付，又能同时原生地拥有金融级的高可用、一致性特性和互联网的海量并发、弹性伸缩等云原生基础架构能力。蚂蚁金服期望通过逐步向社区（链接如下）：
体系内的各个组件，帮助大家更加敏捷稳妥地实现金融级云原生架构。我们也非常欢迎来自技术社区和各行业的伙伴能够参与共同探讨、交流和共建，使其更加完善和稳固，满足更多金融级架构转型升级的需求。七.交流社群
本文由325游戏 （www.325qp.net）整理发布
删除。
网友评论 ()条 查看