【分布式事务】GitHub上分布式事务框架压测性能对比

一、前言

      随着项目逐步以微服务开发为趋势,逐渐呈现一个服务对应一个数据库。从中产生了分布式事务的问题:一个操作先后调用不同的服务,要保证服务间的事务一致性,这就是分布式事务解决的问题。

      本次调研,根据github上star排名进行调研,主要调研了hmily和bytetcc两种分布式事务框架。

二、选型原则

      本次调研主要是根据CAP和BASE理论进行,主要要保证数据的可用性、分区容错性、最终一致性。

三、调研框架介绍

hmily介绍

      Hmily是由碧桂园工程师开发,高性能异步分布式事务TCC框架。

      Github地址:https://github.com/yu199195/hmily

特点:
1、 采用disruptor框架进行事务日志的异步读写,与RPC框架的性能毫无差别。
2、 RPC框架支持 : dubbo,motan,springcloud。
3、 支持嵌套事务(Nested transaction support).
4、 采用disruptor框架进行事务日志的异步读写,与RPC框架的性能毫无差别。
5、 支持SpringBoot-starter 项目启动,使用简单。
6、 本地事务存储支持 : redis,mongodb,zookeeper,file,mysql。
7、 事务日志序列化支持 :java,hessian,kryo,protostuff。
8、 采用Aspect AOP 切面思想与Spring无缝集成,天然支持集群。
9、 内置经典的分布式事务场景demo工程,并有swagger-ui可视化界面可以快速体验。
10、 异步confirm 和 cancel,保证数据一致性
11、 使用Guava Cache

Bytetcc介绍

      Bytetcc是由北京新奥集团工程师开发,是一个兼容JTA规范的基于TCC机制的分布式事务管理器。目前开发到了第五版,稳定版本为第四版,本次调研为第四版(0.4.x)。

      GitHub地址:https://github.com/liuyangming/ByteTCC

特点:
1、支持Spring容器的声明式事务管理;
2、支持普通事务、TCC事务、saga事务等事务机制;
3、支持多数据源、跨应用、跨服务器等分布式事务场景;
4、支持长事务;
5、支持dubbo服务框架;
6、支持spring cloud;

四、压测机器情况说明

压测机

  • Windows 10 企业版
  • 16GB
  • Jmeter

服务器

服务器cpu 服务器内存 服务器网络 压测机cpu 服务器cpu配置 服务器内存配置 rds的cpu情况,可能多个 redis的cpu情况,可能多个
4 16 公司内网 4 4核 4G 4 没有使用

五、压测报告

【分布式事务】GitHub上分布式事务框架压测性能对比_第1张图片

【分布式事务】GitHub上分布式事务框架压测性能对比_第2张图片

hmily压测报告

正常执行

接口 总数 平均响应时间 中间数 90% 95% 99% 最小响应时间 最大响应时间 错误率 吞吐量 每秒接受消息 每秒发送发送消息 线程数
Pay 500000 225 215 347 394 513 13 1374 0 438.7 51.41 87.82 100

      测试结果分析:测试结果发现,吞吐量比较高,但是hmily存在优化的地方,当前版本异步执行confirm和cancel的速度比较慢,且在高并发情况下存在数据不一致问题:

      例如:
      一共执行10w条数据,目标结果:库存-10w , 账户-10w。但是最终执行结果:库存和账户的剩余量不一样。不能保证数据的最终一致性。

      Cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第3张图片

      DB cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第4张图片

带回滚操作执行

接口 总数 平均响应时间 中间数 90% 95% 99% 最小响应时间 最大响应时间 错误率 吞吐量 每秒接受消息 每秒发送发送消息 线程数
Pay 200000 1573 1384 2703 3246 5815 48 11596 0 62.2 32.02 12.45 100

      Cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第5张图片

      DB cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第6张图片

Bytetcc 压测报告

正常执行

接口 总数 平均响应时间 中间数 90% 95% 99% 最小响应时间 最大响应时间 错误率 吞吐量 每秒接受消息 每秒发送发送消息 线程数
Pay 500000 1197 1180 1534 1652 1900 85 2953 0 106.9 14.43 16.71 100

      测试结果分析:吞吐量比较低,可以保证数据的最终一致性。比较稳定。

      Cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第7张图片

DB cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第8张图片

带回滚操作执行

接口 总数 平均响应时间 中间数 90% 95% 99% 最小响应时间 最大响应时间 错误率 吞吐量 每秒接受消息 每秒发送发送消息 线程数
Pay 60000 4006 3556 4491 4973 21972 100 10012 0 48.6 9.1 9.64 100

      Cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第9张图片

      DB cpu:
【分布式事务】GitHub上分布式事务框架压测性能对比_第10张图片

六、小结

      小编只是通过Jmeter对两个比较火的分布式事务框架进行了压测,其中的业务逻辑是一样的,性能也是有不同的。

      测试的代码地址:

      hmily:https://github.com/AresKingCarry/hmilyDemo
      Bytetcc:https://github.com/AresKingCarry/ByteTccDemo

你可能感兴趣的:(➤,JAVA提高篇,➤,框架篇)