seata
如下图所示,Seata 中有三大模块,分别是 TM、RM 和 TC。 其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起,TC 作为 Seata 的服务端独立部署。
![](https://i-blog.csdnimg.cn/blog_migrate/32442682eb0c5fb9f9140be3341cd1e7.png)
在 Seata 中,分布式事务的执行流程:
TM 开启分布式事务(TM 向 TC 注册全局事务记录);
按业务场景,编排数据库、服务等事务内资源(RM 向 TC 汇报资源准备状态 );
TM 结束分布式事务,事务一阶段结束(TM 通知 TC 提交/回滚分布式事务);
TC 汇总事务信息,决定分布式事务是提交还是回滚;
TC 通知所有 RM 提交/回滚 资源,事务二阶段结束。
2.3 分布式事务 Seata 解决方案
Seata 会有 4 种分布式事务解决方案,分别是 AT 模式、TCC 模式、Saga 模式和 XA 模式。
![](https://i-blog.csdnimg.cn/blog_migrate/b28e7fddece4b14afd88b0b9bfc17872.png)
2.3.1 AT 模式
今年 1 月份,Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。
![](https://i-blog.csdnimg.cn/blog_migrate/f1a3af5a91e38fdadd86e5e4fbd86384.png)
AT 模式如何做到对业务的无侵入 :
一阶段:
以下文中的行锁都是全局锁
在一阶段,Seata 会拦截“业务 SQL”,首先解析 SQL 语义,找到“业务 SQL”要更新的业务数据,之后要获得本地锁,在业务数据被更新前,将其保存成“before image”,然后执行“业务 SQL”更新业务数据,在业务数据更新之后,再将其保存成“after image”,最后生成行锁,然后再释放本地锁。最后一阶段执行完毕,事务只持有一个行锁。这样保证了一阶段操作的原子性。
![](https://i-blog.csdnimg.cn/blog_migrate/a09b51272b8a6584b6ec8718ea1ba610.png)
二阶段提交:
二阶段TC根据所有的分支事务执行结果判断,如果是提交的话,因为“业务 SQL”在一阶段已经提交至数据库, 所以 Seata 框架只需将一阶段保存的快照数据和行锁(全局锁)删掉,完成数据清理即可。
![](https://i-blog.csdnimg.cn/blog_migrate/aeb4797054b5c0315a5c8db440992331.png)
二阶段回滚:
二阶段如果是回滚的话,Seata 就需要回滚一阶段已经执行的“业务 SQL”,还原业务数据。回滚方式便是用“before image”还原业务数据;但在还原前要首先要校验脏写,对比“数据库当前业务数据”和 “after image”,如果两份数据完全一致就说明没有脏写,可以还原业务数据,如果不一致就说明有脏写,出现脏写就需要转人工处理。
![](https://i-blog.csdnimg.cn/blog_migrate/e9f0c199d2aae68631b2f1021f2940e1.png)
AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成,用户只需编写“业务 SQL”,便能轻松接入分布式事务,AT 模式是一种对业务无任何侵入的分布式事务解决方案。
为什么要有行锁(全局锁)呢?
试想一下,我们有三个事务,分别是A、B、C,业务要求A、B、C三个事务的执行是同步的,这就要求我们要对这三个事务建立一个分布式事务,如果没有全局锁的限制
A事务在本机执行完毕,释放本地锁
B事务在本机执行完毕,释放本地锁
C事务在本机执行完毕,释放本地锁
根据A、B、C三个事务执行状态,二阶段决定提交还是回滚
看起来好像没什么问题,但是如果在A事务执行完毕,释放锁的时候,A2事务也要执行,并且修改A事务修改过的数据,如果没有全局锁,会导致A事务失效,为了分布式事务的一致性,需要添加全局锁作为保障。
并且二阶段会进行脏数据的校验,相当于又加了一层保护。
2.3.2 TCC 模式
2019 年 3 月份,Seata 开源了 TCC 模式,该模式由蚂蚁金服贡献。TCC 模式需要用户根据自己的业务场景实现 Try、Confirm 和 Cancel 三个操作;事务发起方在一阶段 执行 Try 方式,在二阶段提交执行 Confirm 方法,二阶段回滚执行 Cancel 方法。
![](https://i-blog.csdnimg.cn/blog_migrate/c87717cc13f3dc221845f2e618fc8c5c.png)
TCC 三个方法描述:
Try:资源的检测和预留;
Confirm:执行的业务操作提交;要求 Try 成功 Confirm 一定要能成功;
Cancel:预留资源释放。
业务模型分 2 阶段设计:
用户接入 TCC ,最重要的是考虑如何将自己的业务模型拆成两阶段来实现。
以“扣钱”场景为例,在接入 TCC 前,对 A 账户的扣钱,只需一条更新账户余额的 SQL 便能完成;但是在接入 TCC 之后,用户就需要考虑如何将原来一步就能完成的扣钱操作,拆成两阶段,实现成三个方法,并且保证一阶段 Try 成功的话 二阶段 Confirm 一定能成功。
![](https://i-blog.csdnimg.cn/blog_migrate/c5bd8e11a1d2d9c376c4abb54eb77c89.png)
如上图所示,
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 模式高很多。
2.3.3 Saga 模式
Saga 模式是 Seata 即将开源的长事务解决方案,将由蚂蚁金服主要贡献。在 Saga 模式下,分布式事务内有多个参与者,每一个参与者都是一个冲正补偿服务,需要用户根据业务场景实现其正向操作和逆向回滚操作。
分布式事务执行过程中,依次执行各参与者的正向操作,如果所有正向操作均执行成功,那么分布式事务提交。如果任何一个正向操作执行失败,那么分布式事务会去退回去执行前面各参与者的逆向回滚操作,回滚已提交的参与者,使分布式事务回到初始状态。
![](https://i-blog.csdnimg.cn/blog_migrate/30bf0a8a08f7489c055806f9715f1c7e.png)
Saga 模式下分布式事务通常是由事件驱动的,各个参与者之间是异步执行的,Saga 模式是一种长事务解决方案。
2.3.4 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 事务都提交或者都回滚。
![](https://i-blog.csdnimg.cn/blog_migrate/1caae0fad108b69aadfb8f8d424e5720.png)
XA 模式下,用户只需关注自己的“业务 SQL”,Seata 框架会自动生成一阶段、二阶段操作;XA 模式的实现如下:
![](https://i-blog.csdnimg.cn/blog_migrate/8de814dec446da1618cd81885b563bae.png)
一阶段:
在 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 模式实现更加轻量化。
分布式事务在蚂蚁金服的实践
蚂蚁金服从 2007 年开始研发和应用分布式事务中间件,用 TCC 模式解决各类金融场景的数据一致性问题,后续又演进出 FMT(AT)、XA、Saga 等模式,各种模式分别适用于各类业务场景。我们决定将蚂蚁金服多年的技术积累开源出来,与社区共享蚂蚁金服的科技成果。
蚂蚁金服内部的分布式事务产品,在实现原理和使用方式上,与 Seata 类似,不同的是,为了支持双十一,对性能进行了极致优化,为了支持金融系统的高可用容灾,借助蚂蚁金服三地五中心架构实现了分布式事务服务的高可用容灾;接下来主要介绍蚂蚁金服在性能优化和高可用容灾方面的实践经验。
![](https://i-blog.csdnimg.cn/blog_migrate/9239c5c8c17e098231d7aaeeef952bd2.png)
3.1 极致性能优化
3.1.1 同库模式
通常,一个 TM 会产生一笔主事务日志,一个 RM 会产生一条分支事务日志,每个分布式事务由一个 TM 和若干 RM 组成,一个分布式事务总共会有 1+N 条事务日志(N 为 RM 个数)。
在默认情况下,分布式事务执行过程中客户端将事务日志发送给服务端,服务端再将事务日志存储至数据库中,一条事务日志的存储链路会有 2 次 TCP ,分别是“客户端到服务端”和“服务端到数据库”, 我们称这种模式为异库模式。
在异库模式下,分布式事务存储事务日志总共需要 2*(1+N) 次左右的 TCP 通信。在 RM 数量较少的业务场景下,分布式事务性能还能接收,但有些业务场景下 RM 数量较多,此时事务内 TCP 数量也会增多,分布式事务性能急剧下降。
![](https://i-blog.csdnimg.cn/blog_migrate/f3799741d03638fd31ab4285705d8f9c.png)
在事务执行过程中,客户端和服务端进行通信的目的是为了存储事务日志。如果客户端在存储事务日志时,绕过服务端直接将事务日志写入数据库(如上图“同库模式”所示),那么一笔事务日志的存储链路就由原来的 2 次 TCP 变成只需访问一次数据库便可,每条事务日志的存储减少了一次 TCP 通信,整个分布式事务就减少了 N+2 次 TCP 请求,分布式事务的性能大幅提升。我们将客户端直接将事务日志存储至数据库的模式称为同库模式。
3.1.2 二阶段异步执行
通常情况下,分布式事务发起方会依次执行一阶段和二阶段方法,然后结束分布式事务,返回结果。如果让分布式事务发起方执行完一阶段之后马上结束并返回结果,二阶段交由独立的线程或者进程异步执行,这样分布式事务的二阶段会晚几秒钟或者若干分钟执行,但事务的最终结果不会有任何改变。
二阶段异步执行之后,分布式事务的最终结果不会有任何影响,但是事务发起方要执行的内容减少一半(一阶段和二阶段都执行变成只执行一阶段),直观的用户感受是分布式事务的性能提升了 50%。
![](https://i-blog.csdnimg.cn/blog_migrate/4e701c042aa03b5b68a94b876c1333ce.png)
3.2 分布式事务高可用
为了保障金融系统的高可用,分布式事务服务必须达到 99.99% 的可用率。分布式事务使用了蚂蚁金服的三地五中心架构部署,在每个机房都独立部署分布式事务服务,分布式事务服务是无状态的,而底层数据库副本在各机房间也是双向同步,这样业务流量从一个机房切到另外一个机房,分布式事务服务不会对业务有任何影响,从而保证了分布式事务服务的高可用。
![](https://i-blog.csdnimg.cn/blog_migrate/d1221c4dd036c7ba88f0ceb6f2fb9522.png)
总结
在分布式架构演进中,蚂蚁金服对数据库进了水平拆分,对服务面向功能进行了服务化拆分,从而出现了跨服务、跨数据库的业务数据一致性挑战。
2007 年,蚂蚁金服自主研发分布式事务中间件经历 12 年的严苛业务锤炼。2019 年,将多年的技术积累分享给开源分布式事务 Seata,并持续投入社区共建。目前 Seata 提供了 AT、TCC、Saga 和 XA 四种模式,每一种模式分别有各自的应用场景,丰富的解决方案帮助用户解决给了各类场景的数据一致性问题。
最后一部分,分享了蚂蚁金服具体的实践。为了支持双十一的高性能需求,对分布式事务进行了极致的性能优化,例如同库模式、二阶段异步执行。为了使金融服务的可用性达到 99.99%,蚂蚁金服分布式事务采用三地五中心架构,异地多活的部署模式保障了分布式事务服务的高可用。