蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理 Posted 2021-04-25 金融级分布式架构
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了蚂蚁金服分布式事务实践解析 | SOFAChannel#12 直播整理相关的知识，希望对你有一定的参考价值。
<SOFA:Channel/>，有趣实用的分布式架构频道。
本文根据 SOFAChannel#12 直播分享整理，主题：蚂蚁金服分布式事务实践解析。回顾视频以及 PPT 查看地址见文末。
欢迎加入直播互动钉钉群 : 30315793，不错过每场直播。
大家好，我是今天分享的讲师仁空，目前是蚂蚁金服分布式事务产品的研发。今天跟大家分享的是蚂蚁金服分布式事务实践解析，也就是分布式事务 Seata 在蚂蚁金服内部的实践。
支付宝支付产品在 2003 年上线的时候，那时候的软件形态是单体应用，在一个应用内完成所有的业务逻辑操作。随着软件的工业化，场景越来越复杂，软件也越做越大，所有的业务在一个应用内去完成变的不可能，出现了软件模块化、服务化。
在从单体应用升级到分布式架构过程中，很自然得需要进行业务服务拆分，将原来糅在一个系统中的业务进行梳理，拆分出能独立成体系的各个子系统，例如交易系统、支付系统、账务系统等，这个过程就是服务化。业务服务拆分之后，原来一个服务就能完成的业务操作现在需要跨多个服务进行了。
另一个就是数据库拆分，分库分表。原来的单体数据库存不下的这么多信息，按服务维度拆库，比如把用户相关的存一起，形成用户库，订单放一块形成订单库，这个是拆库的过程；另一个是拆表，用户信息按照用户 ID 散列到不同的 DB 中，水平拆分，数据库的容量增大了。这样分库分表之后，写操作就会跨多个数据库了。
我们可以看到，在分布式架构中，跨数据库、跨服务的问题是天然存在的。一个业务操作的完成，需要经过多个服务配合完成，这些服务操作的数据可能在一个机房中，也可能跨机房存在，如果中间某一个服务因为网络或机房硬件的问题发生了抖动，怎么保证这笔业务最终的状态是正确的，比如支付场景，怎么防止我转钱给你的过程中，我的钱扣了，而对方的账户并没有收到钱。这个就是业务最终一致性的问题，是分布式事务需要解决的问题。
针对这个问题，理论界也提出了解决方案，其中最为人熟知的就是二阶段协议了，简称2PC（Two Phase Commitment Protocol）两阶段提交协议。
两阶段提交协议，就是把整个过程分成了两个阶段，这其中，它把参与整个过程的实体分成了两类角色，一个叫事务管理器或事务协调者，一个叫资源管理器，事务管理器我们也把它叫做事务发起方，资源管理器称为事务参与者。
两个阶段，第一个阶段是资源准备阶段，比如我要转账，我要先查询下我的余额够不够，够的话我就把余额资源预留起来，然后告诉发起方“我准备好了”，第二个阶段，事务发起方根据各个参与者的反馈，决定事务的二阶段操作是提交还是取消。
另一个协议是 TCC 协议，各个参与者需要实现 3 个操作：Try、Confirm 和 Cancel，3 个操作对应 2 个阶段，Try 方法是一阶段的资源检测和预留阶段，Confirm 和 Cancel 对应二阶段的提交和回滚。
图中，事务开启的时候，由发起方去触发一阶段的方法，然后根据各个参与者的返回状态，决定二阶段是调 Confirm 还是 Cancel 方法。
2019年，蚂蚁金服跟阿里巴巴共同开源了分布式事务 Seata ，目前 Seata 已经有 TCC、AT、Saga 模式，Seata 意为：Simple Extensible Autonomous Transaction Architecture，是一套一站式分布式事务解决方案。今天的分享也是 Seata 在蚂蚁金服内部的实践。
基于上述的理论，接下来我们详细看下蚂蚁金服的分布式事务实现。
经过多年的发展，蚂蚁金服内部针对不同的场景发展了几种不同的模式，最早的是 TCC 模式，也就是上面讲的 Try - confirm - Cancel，我们定义接口规范，业务自己实现这 3 个操作。这个模式提供了更多的灵活性，因为是业务自己实现的，用户可以介入两阶段提交过程，以达到特殊场景下的自定义优化及特殊功能的实现，这个模式能几乎满足任何我们想到的事务场景，比如自定义补偿型事务、自定义资源预留型事务、消息事务等场景。TCC 模式广泛用于蚂蚁金服内部各金融核心系统。
这里要强调一点的是，TCC 模式与底层数据库事务实现无关，是一个抽象的基于 Service 层的概念，也就是说，在 TCC 的范围内，无论是关系型数据库 mysql
TCC 模式的好处是灵活性，弊端是牺牲了易用性，接入难度比较大，所有参与者需要进行改造提供 Try - Confirm - Cancel 三个方法。为了解决 TCC 模式的易用性问题，蚂蚁金服分布式事务推出了框架管理事务模式（Framework - Managed Transactions，简称 FMT），也就是 Seata 中的 AT 模式。FMT 模式解决分布式事务的易用性问题，最大的特点是易于使用、快速接入、对业务代码无侵入。
Saga 模式是基于冲正模型实现的一个事务模式，现在的银行业金融机构普遍用的是冲正模型。
这期我们重点讲 TCC 和 FMT，关于 Saga 模式，之前 Saga 模式也有专场直播分享过，感兴趣的可以看一下之前的直播回顾：《
》。
首先看下 TCC 模式，主要包含一下几个模块：
举个例子，比如在这个流程图中，存在一个发起方和两个参与者，两个参与者分别实现了 Try、Confirm 和 Cancel 接口，第一阶段被包含在发起方的本地事务模版中（图中黄颜色的两条虚线就是发起方本地事务的范围），也就是说发起方负责调用各个参与者的一阶段方法，发起方的本地事务结束后，开始执行二阶段操作，二阶段结束则整个分布式事务结束。
二阶段是通过 S pring 提供的事务同步器实现的，发起方在发起一个分布式事务的时候，会注册一个事务同步器，当发起方本地事务结束的时候，会进入事务同步器的回调方法中。如果发起方的本地事务失败，则在回调中自动回滚所有参与者。如果发起方的本地事务成功，则二阶段自动提交所有参与者。二阶段结束后，删除所有事务记录。
总结一下：
事务发起方是分布式事务的协调者；
分布式事务必须在本地事务模板中进行，发起方本地事务的最终状态（提交或回滚）决定整个分布式事务的最终状态；
发起方主职责：开启一个分布式事务 + 调用参与者一阶段方法。发起方实现的时候，首先是开启一个本地事务，调用 Start 开启分布式事务，框架会自动注册一个 Spring 事务同步器，然后发起方发起对参与者 Try 方法的调用，当有一个 Try 方法失败，则阻断发起方本地事务，状态置为回滚；否则，所有的参与者 Try 成功，整个分布式事务的状态就是提交。框架会利用事务同步器自动去执行参与者的二阶段方法；
使用数据库持久化记录事务数据，也就是会跟踪发起方和各个参与者的状态，我们称为主事务状态和分支事务状态。这样我们就知道一个大事务整体是处于什么状态，每个参与者又是什么状态，当一笔事务失败时，我们就能捞起那些失败的参与者，进行补偿重试；
上面讲了整个流程以及发起方的实现内容，现在看下业务在实现参与者的时候，需要遵循以下规范：
业务模型分二阶段设计；
幂等控制；
并发控制；
允许空回滚；
防悬挂控制；
二阶段设计和幂等控制比较容易明白。二阶段设计就是一阶段的资源预留和二阶段的提交回滚。
比如以扣钱场景为例，账户 A 有 100 元，要扣除其中的 30 元。一阶段要先检查资源是否足够，账户余额是否大于等于 30 块，资源不足则需要立马返回失败；资源足够则把这部分资源预留起来，预留就是锁资源，锁的粒度可大可小，尽量是按照最小粒度、尽快释放的原则来，比如这里引入一个“冻结部分”的字段，“可用余额”在一阶段后就能立马得到释放，锁的是冻结字段。
二阶段，如果是提交则真正扣除冻结的 30 元；如果是回滚的话，则把冻结部分加回可用余额里。
我们看个具体的客户案例，网商银行在使用 TCC 时，划分了三层，最上一层是具体的业务平台，承接着外部不断变化的业务需求；中间是资产交换服务，是事务发起方层，由它来发起和编排各种不同的事务链路；最底下一层是事务参与者层，提供最基础的服务，比如存款核心提供的存入、支出、冻结、解冻服务，借记账务的各种原子服务等。
看下我们日常生活中常见的几个金融业务场景，支出、存入、冻结、解冻、提现、手续费和销户。提现场景，比如信用卡提现至银行卡，类似 A 到 B 的转账；手续费，跟转账类似。
下面重点介绍一下其他 4 个场景：支出（扣款）、存入（记入）、冻结和解冻四个 Case。
首先，看下账户表的设计，前面说过，在设计的时候，需要尽可能减少锁的时间和锁的粒度，这里账户表有这 4 个字段：当前余额、未达金额、业务冻结金额和预冻结金额。用户看到的余额 = 当前金额 - 预冻结 - 业务冻结金额。
先来看下支出（扣款）场景下，账户表里各字段的数额变化。初始状态下，显示的账户余额，和当前余额是一致的。TCC 的一阶段检查并预留资源，这里对应的资源是“预冻结金额”字段，预冻结金额设置为 100 元，当前余额不变。因为 100 块被预冻结了，显示给用户的可用余额现在是 900 元。如果二阶段是提交的话，就释放预冻结金额，扣除当前余额，账户的当前余额就是 900 元。如果二阶段不是提交，是回滚，这里就是把一阶段的资源释放，也就是把预冻结金额释放回去，显式的账户余额重新变成 1000 元。
上面是支出（扣款）场景，再来看下存入的场景。初始状态还是当前余额和显式的可用余额都是1000元。因为是存入，一阶段的话就是“未达金额”加 100 元，显示的可用余额还是不变。二阶段如果是提交，就把未达金额清除，把这部分的钱加到当前余额，当前余额就是 1100 元了。如果二阶段是回滚，直接清除一阶段的未达金额即可。
冻结场景则是在一阶段是资源预留，就是预冻结，预冻结金额字段设置为 100 元，显示给用户的可用余额也要少 100 块。二阶段如果是提交，就是真正冻结，把预冻结金额释放，添加业务冻结金额。二阶段回滚的话，就是把一阶段的预冻结释放。
最后看下解冻场景，一阶段检查账户状态是不是可用，二阶段如果提交，就释放冻结金额，显示的可用余额就多了 100 元。二阶段如果是回滚状态，就什么都不用做。
以上分享了接入 TCC 如何进行二阶段设计以及如何进行资源预留，用实际的金融场景分析了下 TCC 一二阶段需要做的事情。因为二阶段设计是 TCC 接入的关键，所以进行了重点阐述。接下来我们继续看 TCC 设计的其他规范。
幂等控制，就是 Try-Confirm-Cancel 三个方法均需要保持幂等性。
无论是网络数据包重传，还是异常事务的补偿执行，都会导致 TCC 服务的 Try、Confirm 或者 Cancel 操作被重复执行；用户在实现 TCC 服务时，需要考虑幂等控制，即 Try、Confirm、Cancel 执行一次和执行多次的业务结果是一样的。
并发控制即当两个并发执行的分布式事务操作同一个账号时，冻结的部分是相互隔离的，也就是 T1 冻结金额只能被事务 1 使用，T2 冻结金额只能被事务 2 使用。冻结资源与事务 ID 之间建立关联关系。
首先对空回滚的定义就是 Try 未执行，Cancel 先执行了。正常是一阶段的请求先执行，然后才是二阶段的请求。出现空回滚的原因，是网络丢包导致的，调用 Try 方法时 RPC timeout 了，分布式事务回滚，触发 Cancel 调用；参与者未收到 Try 请求而收到了 Cancel 请求，出现空回滚。
悬挂的定义是 Cancel 比 Try 先执行。不同于空回滚，空回滚是 Try 方法的请求没有收到。悬挂是 Try 请求到达了，只不过由于网络拥堵，Try 的请求晚于二阶段的 Cancel 方法。
调用 TCC 服务 Try 方法，网络拥堵（未丢包），RPC超时；
分布式事务回滚；
TCC 服务 Cancel 被调用，执行了空回滚；整个分布式事务结束；
被拥堵的 Try 请求到达 TCC 服务，并被执行；出现了二阶段 Cancel 请求比一阶段 Try 请求先执行的情况，TCC 参与者悬挂；
解决悬挂的问题，可以跟踪事务的执行，如果已经回滚过了，一阶段不应该正常执行，这时候要拒绝 Try 的执行。
接下来我们来看一下 FMT（Framework-Managerment-Transaction）框架管理事务模式。
之前介绍几个事务模式的时候，说过 TCC 模式虽然灵活，功能强大，能做很多定制和优化，但是使用难度上比较大，业务系统要进行二阶段改造，编码工作非常多。
针对那些对性能要求并不高，业务体量并不大的中小业务，我们推出了 FMT 模式——框架管理事务，从名字上看，就是大部分工作由框架自动完成，业务只需要关注实现自己的业务 SQL 即可。
FMT 还是基于二阶段的模型，业务只需要关注一阶段实现自己的业务 SQL，二阶段的自动提交回滚由框架来完成。
框架托管的二阶段，需要基于对一阶段的分析。在一阶段中，会执行下面几个步骤：对 SQL 进行解析，提取表的元数据，保存 SQL 执行前的值，执行 SQL，保存执行后的快照，保存行锁。
查询操作不涉及事务，我们这里以一个更新操作为例，首先要对操作的 SQL 进行语法语义分析，提取出关于这条记录的全部信息，包括是属于哪张表、查询条件是什么、有哪些字段、这些记录的主键等，这些信息可以通过 JDBC MetaData API 就能拿到。
然后我们开始保存执行前的快照数据，把目标记录的所有字段的当前值存到 undo log 里，存完后真正执行 SQL，SQL 执行后原来的一些字段值就已经产生变化了，我们把新的快照数据存到 redo log 里。最后把表名称和记录主键值存到行锁表，代表当前这个事务正在操作的是哪些记录。
有了这些信息后，框架就完全能自己去执行二阶段操作了。比如，当事务需要进行二阶段提交，因为在一阶段里业务 SQL 已经执行了，二阶段只需要把产生的中间数据删掉即可。当二阶段回滚时，因为我们保存了 SQL 执行的快照数据，所以还原回执行前的快照数据即可，同时把中间数据删掉。
这里我们知道了 undo 和 redo log 的作用，接下来讲讲行锁。行锁是用来进行并发控制的。当一个事务在操作一条记录前，会先去行锁表里查下有没有这条记录的锁信息，如果有，说明当前已经有一个事务抢占了，需要等待那个事务把锁释放。图中，事务 1 在一阶段对记录上锁，这个时候事务 2 进来，只能等待，等事务 1 二阶段提交，把锁释放，事务 2 这时候才能加锁成功。
最后，我们看看在蚂蚁金服内部，针对双十一、双十二这种大促，为了达到更好的性能状态，做的一些优化。
一个是二阶段异步化，因为一阶段的结果已经能决定整个事务的状态了，而且资源也都预留好了，剩下的二阶段可以等请求峰值过后再去执行。这样，分布式事务耗时由执行 Try + Confirm 或者 Try + Cancel 缩减成 Try，提高了吞吐量。虽然结果有延迟的，但最终结果无任何影响。
异步的二阶段方法，在请求洪峰过后，会由事务恢复服务捞起执行。
另一个优化，在事务记录上。分布式事务在推进过程中，会记录事务日志，如果这个事务日志是放到 Server 这边的，发起方更新事务状态时，需要跨 RPC 调用到Server方那边，影响分布式事务的性能。如果将事务日志存在业务数据库，则每次记录状态的就是业务本地执行的，减少 RPC 调用次数，从而提升了性能。
以上就是本期分享的全部内容，我们先从事务产生的背景入手，在现在分布式架构的体系结构下，跨服务协同调用是常态，而网络、数据库、机器等都具有不可靠性，如果保证这中间操作要么全部成功，要么全部失败，是大家面临的共同问题，特别是金融场景下，对解决这个问题更有迫切性，蚂蚁金服作为一家金融科技公司，在这方面也进行了探索，积累了很多经验。
在介绍蚂蚁金服的分布式事务中间件之前，先介绍了一些分布式事务的理论背景，包括两阶段协议和 TCC 协议。基于理论背景，重点介绍了蚂蚁金服在分布式事务上 TCC、FMT 模式的应用，分享了实现原理和设计规范以及 TCC 二阶段设计等。最后介绍了针对双十一双十二这种大促活动，如何进行二阶段异步化和同库模式的优化，来支撑零点峰值时的洪峰请求。
以上就是本期分享的全部内容，如果大家对蚂蚁金服在分布式事务中的实践以及 Seata 有问题跟兴趣，也可以在群内（群号：30315793）与我们交流。
https://tech.antfin.com/community/live/1119/data/980
