引子
本文不剖析业内分布式组件，只剖析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实现 |
|
|
|
| TCC | 二阶段提交的应用层实现。 |
|
|
|
| SAGA | 逆向按顺序回滚（借鉴SAGAS论文思路实现），其实就是业内泛补偿方案的一种实现。 |
|
|
|
三、性能测试
共用一个业务场景，同一个测试方案。从请求损耗、并发吞吐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官网还提供了事务监控后台，有时候需要人工接入时，可以很方便的操作。
=======================================
本文测试数据来源于同事李总，特此感谢！
如果你觉得本文对你有点帮助的话，记得在右下角点个“推荐”哦，博主在此感谢！
