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

前言

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

测试环境

个人电脑：

• Intel® Core™ i7-8750H CPU @ 2.20GHz 2.21 GHz
• 内存：16.0 GB
• 系统：Windows 10 专业版

组件：

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

提交测试

全局事务的路径为，用户服务扣除余额=》订单服务添加一个订单=》库存服务扣除库存。

并发总数设置为1W次，并发请求数每次增加10。

并发 10

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

并发 20

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

并发 30

聚合报告：

前面开始的线程：

最后的线程：

订单数：

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

并发 100

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

回滚测试

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

并发10

数据无异常，全部回滚成功：

并发30

数据无异常，全部回滚成功：

并发100

数据无异常，全部回滚成功，吞吐量在50/S。

不需要全局事务测试

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

并发100

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

总结

1. 数据一致性

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

2. 吞吐量

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

3. 成功率

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

4. 响应时间

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

5. 注意事项

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