Seata入门系列(26)Seata压力测试

前言

在了解了Seata 的使用和基本原理后&＃xff0c;尝试进行了一把简单的压测&＃xff0c;看看在高并发情况下是否有其他问题。

测试环境

个人电脑&＃xff1a;

• Intel® Core™ i7-8750H CPU &＃64; 2.20GHz 2.21 GHz
• 内存&＃xff1a;16.0 GB
• 系统&＃xff1a;Windows 10 专业版

组件&＃xff1a;

• JDK 1.8
• nacos 2.0.3
• Seata 1.4.2&＃xff08;Nacos 注册中心&＃xff0c;本地文件配置中心&＃xff0c;记录数据库存储会话&＃xff09;
• Spring Boot 2.2.13
• Mariadb 10.1
• 账户、订单、库存单体服务部署

提交测试

全局事务的路径为&＃xff0c;用户服务扣除余额&＃61;》订单服务添加一个订单&＃61;》库存服务扣除库存。

并发总数设置为1W次&＃xff0c;并发请求数每次增加10。

并发 10

在该并发量下&＃xff0c;成功下单1W&＃xff0c;也没有什么异常&＃xff0c;检查数据&＃xff0c;也没有数据不一致的问题。

并发 20

在该并发量下也没有什么异常&＃xff0c;但是偶尔某个响应时间明显长了很多。

并发 30

聚合报告&＃xff1a;

前面开始的线程&＃xff1a;

最后的线程&＃xff1a;

订单数&＃xff1a;

从上可以看到&＃xff0c;当并发请求数达到30时&＃xff0c;吞吐量仍然在20/S 左右&＃xff0c;并且响应时间很长&＃xff0c;存在异常&＃xff0c;有一个订单失败。猜测响应时间过长的原因在于全局锁的竞争等待。

并发 100

在该请求并发情况下&＃xff0c;吞吐量明显下降&＃xff0c;异常率也飙升&＃xff0c;失败了1000多个订单。但数据任然保持了一致性。

回滚测试

在库存服务中&＃xff0c;抛出异常&＃xff0c;测试在全局回滚的状态下&＃xff0c;是否有并发问题。

并发10

数据无异常&＃xff0c;全部回滚成功&＃xff1a;

并发30

数据无异常&＃xff0c;全部回滚成功&＃xff1a;

并发100

数据无异常&＃xff0c;全部回滚成功&＃xff0c;吞吐量在50/S。

不需要全局事务测试

为了对比性&＃xff0c;最后去掉分布式事务注解&＃xff0c;测试下本地事务吞吐量。

并发100

可以看到吞吐量在80/S&＃xff0c;比分布式事务场景下还是高了不少。

总结

1. 数据一致性

在高并发下&＃xff0c;能保持全局事务数据一致性&＃xff0c;没有发现脏数据。

2. 吞吐量

在高并发下&＃xff0c;吞吐量大概在20/S&＃xff0c;性能一般&＃xff0c;所以能不使用分布式事务就不要使用。

3. 成功率

在并发请求数超过20 时&＃xff0c;会爆发异常&＃xff0c;100 并发数下&＃xff0c;异常率为18%。

4. 响应时间

随着并发增加&＃xff0c;响应时间也会增加很多&＃xff0c;主要原因在于&＃xff0c;分布式事务需要全局锁。

5. 注意事项

• 总体性能不高&＃xff0c;在高并发场景下需要搭建集群环境
• 针对某一数据的并发操作&＃xff0c;吞吐量很低&＃xff0c;需要做限流处理&＃xff0c;不然会很卡或者报错