提供了编程的基础技术教程

zl程序教程

您现在的位置是：首页 >  .Net

当前栏目

Seata的技术调研

2023-02-18 16:36:31 时间

引子

本文不剖析业内分布式组件，只剖析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官网还提供了事务监控后台，有时候需要人工接入时，可以很方便的操作。

 

 

 

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

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

 

相关文章