Seata的技术调研

引子

本文不剖析业内分布式组件，只剖析seata这一组件的技术调研。看看是否存在接入价值。

一、概述

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。也是目前最具影响力的分布式事务组件。

本文从核心原理、性能测试两大模块来剖析seata。

根据Seata官网介绍历史如下：

Alibaba（阿里巴巴）

TXC: 淘宝事务组件。阿里巴巴中间件团队从2014年开始启动该项目，以应对应用架构从单点到微服务的变化带来的分布式事务问题。
GTS: 全局事务服务。 TXC作为阿里云中间件产品，自2016年起更名为GTS。
Fescar:Fast & EaSy Commit And Rollback，从2019年开始启动基于TXC/GTS的开源项目Fescar，以便在未来与社区密切合作。

Ant Financial（蚂蚁金服）

XTS: 拓展事务服务。蚂蚁金服中间件团队从2007年开始开发分布式事务中间件，该中间件在蚂蚁金服得到广泛应用，解决了跨数据库和跨服务的数据一致性问题。
DTX: 分布式事务扩展。自2013年起，XTS在蚂蚁金服上线，命名为DTX。

Seata Community（Seata社区）

Seata :简单的可扩展自动事务架构（Seata=Simple Extensible Autonomous Transaction Architecture）。蚂蚁金服加入Fescar，使其成为一个更加中立、开放的分布式事务社区，Fescar更名为Seata。

二、核心原理

2.1 四种事务模式

模式	概述	优点	缺陷	适用场景
XA	二阶段提交的数据库驱动实现，套壳。	对业务侵⼊很小；保证了数据的强一致。(理论上)	强依赖底层数据库驱动实现	对并发不高，性能没要求。数据的强一致要求较高且执⾏时间确定的短事务的场景。
AT	seata自封装UNDO_LOG实现	对业务侵⼊较小（只需要在TM的地方加一个全局事务注解即可）；一阶段释放本地锁，相对于XA性能较好；	对sql支持度不高（具体参照SQL限制）；默认读不隔离，需要特殊处理；	会对业务数据加锁，适合单数据操作不频繁，业务流程不是特别长，且整体业务只包含简单的sql的场景
TCC	二阶段提交的应用层实现。	控制资源锁的粒度变小，高性能；保证数据最终一致性；	对业务侵⼊大，实现难度较大，而且需要按不同失败原因进行应答. 为了满足一致性，需要confirm和cancel实现幂等性。	可自己把控业务的API的场景。业务适合拆分一阶段校验的场景。
SAGA	逆向按顺序回滚（借鉴SAGAS论文思路实现），其实就是业内泛补偿方案的一种实现。	一阶段提交本地事务，无锁，高性能；事件驱动架构，参与者可异步执行，高吞吐；补偿服务易于实现提供了状态机配置WEB端，自定义业务流程。	业务入侵中等，但子事务拆分粒度需好好设计。不保证隔离性。	业务流程长、业务流程多；参与者系统功能包含无法实现TCC时。

三、性能测试

共用一个业务场景，同一个测试方案。从请求损耗、并发吞吐2个重要指标进行测试。

3.1 测试方案

本次采用Apache的开源测试工具Jmeter。
本次测试模拟用户购买商品的业务逻辑，由4个微服务提供支持，具体服务调用如下图。

3.2 请求损耗

本次测试目标是针对Seata的AT、TCC、Saga、XA事务模式下正常的请求，验证在不同事务模式下请求的耗损情况。

测试指标

获取各事务模式下请求的耗损情况；

测试结果

注：脚本采用单线程跑，采集样本数不够大，可能会影响数据的可靠性，如果有条件可以十倍样本数。

3.2 并发吞吐

本次测试是针对Seata的AT、TCC、Saga、XA事务模式下进行分段压力测试（模拟百万账户/商品的随机下单场景），验证在不同并发下，不同事务模式的性能影响情况。

为确保下单数据足够分散，模拟产生了超过100万的账户和商品，并随机组合下单;

测试指标

获取在不同事务模式下单机部署情况下最大TPS值；
在分段并发下，各事务模式的吞吐量变化；

测试结果

吞吐量：

如上图所示，在并发较高的情况下，相比于不使用Seata事务，TCC和Saga事务模式服务的吞吐能力较为接近。而XA事务模式在并发线程超过120之后，吞吐能力急剧下降，当超过并发线程超过140，大量的事务挂起超时，服务已经接近不可用。AT事务模式介于XA与TCC/Saga之间，但整体表现比较稳定。

TPS：

如上图所示，各种事务模式下最大的TPS对比，其中，Saga和TCC事务模式的最大TPS与不使用Seata时较为接近。

四、结论

结合4种模式的对比和性能测试，发现Saga和TCC比较优秀。由于Saga对事物的拆分更细，操作起来耗时更多，请求损耗较大，更适合长事务场景。TCC很明确的拆分为二阶段，整体时间较为可控。但由于Saga官网还提供了事务监控后台，有时候需要人工接入时，可以很方便的操作。

=======================================

本文测试数据来源于同事李总，特此感谢！