TCC 实现框架的压力测试记录
国内主要的开源TCC分布式事务框架包括
分布式事务研究以及功能测试相关结果(RPC、事务日志没有全部验证)
框架名称 | 幂等性 | 嵌套调用 | RPC框架支持 | 默认支持事务日志存储方式 | 可靠性验证 |
---|
tcc-transaction | 框架不支持 | 嵌套调用尝试失败 | 不耦合RPC框架,提供:dubbo、http的相关demo | DB、redis、zk、file | 通过 |
Hmily | 框架不支持 | 嵌套调用尝试失败 | dubbo、motan、springcloud,提供:dubbo相关demo | redis、mongodb、zk,file,DB | 通过 |
ByteTCC | 框架支持 | 嵌套调用尝试失败 | dubbo、springcloud | file | 通过 |
EasyTransaction | 框架支持,业务可选择启用(框架支持情况下影响性能) | 支持嵌套调用 | Dubbo、SpringCloud、Ribbon/Eureka | DB、Redis | 通过 |
压力测试环境说明
环境说明 | 硬件相关 | 框架相关 | 业务场景 |
---|
Mac上基于Eclipse的开发环境,数据库和应用运行在同一个机子上 | CPU:2.9 Core i5 ,硬盘:SSD 内存:8G | Springboot+Dubbo 搭建的最简单框架,jdbc均使用Spring的默认数据源 | 订单、存货、支付 三个服务。模拟:A->B\C 三个服务的调用 |
压力测试结果(因为开发环境,没办法做大数据量测试)
测试内容(Average) | 基准(本地事务) | TccTransaction | Hmily | EasyTransaction |
---|
10线程500次循环 | 21 | 65 | 101 | 54 |
20线程500次循环 | 40 | 173 | 161 | 112 |
50线程500次循环 | 95 | 441 | 402 | 337 |
10线程3000次循环 | 19 | 84.3 | 87 | 57 |
20线程3000次循环 | 37 | 226 | 16 | 118 |
50线程3000次循环 | 106 | 452 | 396 | 331 |
测试内容(Tps) | 基准(本地事务) | TccTransaction | Hmily | EasyTransaction |
---|
10线程500次循环 | 463.8 | 150.5 | 97.6 | 182.5 |
20线程500次循环 | 493.9 | 115 | 122.7 | 176.0 |
50线程500次循环 | 520.4 | 112.9 | 124.6 | 147.2 |
10线程3000次循环 | 502.1 | 118.0 | 114.4 | 171.9 |
20线程3000次循环 | 524.7 | 88.3 | 120.1 | 167.9 |
50线程3000次循环 | 468.3 | 110.0 | 126.1 | 151.0 |
测试结果说明
此次的测试相对比较简单,且在此次测试之前也看了海信的开发团队的测试结果,这里也算一个验证以及补充。在测试EasyTransaction时需注意的是,在服务调用时,业务可指定框架是否启用幂等性支持(启用不启用二者的性能差别较大)。
结论
相比TccTransaction、Hmily而言,EasyTransaction的性能上表现抢眼(在框架不提供幂等性支持情况下)。EasyTransaction启用框架幂等性后性能下降较多。嵌套调用的简单测试来看(A->B->C,三个服务的调用),TccTransaction\Hmily均有测试出不同的问题,EasyTransaction在嵌套测试时,没有发现严重的问题。因时间问题,此次的测试还没有做的特别全面,特别是在嵌套调用、以及幂等性验证方面做的还不够,还有在测试方面使用的是开发环境也没有做到数据库和应用分离。今后有时间会继续补上。以上的测试结果以及结论都是个人观点并在此做个记录,仅供参考:)。