前言测试环境提交测试
并发 10并发 20并发 30并发 100 回滚测试
并发10并发30并发100 不需要全局事务测试
并发100 总结
1. 数据一致性2. 吞吐量3. 成功率4. 响应时间5. 注意事项
前言在了解了Seata 的使用和基本原理后，尝试进行了一把简单的压测，看看在高并发情况下是否有其他问题。
测试环境个人电脑：
Intel® Core™ i7-8750H CPU @ 2.20GHz 2.21 GHz内存：16.0 GB系统：Windows 10 专业版
组件：
JDK 1.8nacos 2.0.3Seata 1.4.2（Nacos 注册中心，本地文件配置中心，记录数据库存储会话）Spring Boot 2.2.13Mariadb 10.1账户、订单、库存单体服务部署 提交测试
全局事务的路径为，用户服务扣除余额=》订单服务添加一个订单=》库存服务扣除库存。
并发总数设置为1W次，并发请求数每次增加10。
并发 10在该并发量下，成功下单1W，也没有什么异常，检查数据，也没有数据不一致的问题。
在该并发量下也没有什么异常，但是偶尔某个响应时间明显长了很多。
聚合报告：
前面开始的线程：
最后的线程：
订单数：
从上可以看到，当并发请求数达到30时，吞吐量仍然在20/S 左右，并且响应时间很长，存在异常，有一个订单失败。猜测响应时间过长的原因在于全局锁的竞争等待。
在该请求并发情况下，吞吐量明显下降，异常率也飙升，失败了1000多个订单。但数据任然保持了一致性。
在库存服务中，抛出异常，测试在全局回滚的状态下，是否有并发问题。
并发10数据无异常，全部回滚成功：
数据无异常，全部回滚成功：
数据无异常，全部回滚成功，吞吐量在50/S。
为了对比性，最后去掉分布式事务注解，测试下本地事务吞吐量。
并发100可以看到吞吐量在80/S，比分布式事务场景下还是高了不少。
在高并发下，能保持全局事务数据一致性，没有发现脏数据。
2. 吞吐量在高并发下，吞吐量大概在20/S，性能一般，所以能不使用分布式事务就不要使用。
3. 成功率在并发请求数超过20 时，会爆发异常，100 并发数下，异常率为18%。
4. 响应时间随着并发增加，响应时间也会增加很多，主要原因在于，分布式事务需要全局锁。
5. 注意事项总体性能不高，在高并发场景下需要搭建集群环境针对某一数据的并发操作，吞吐量很低，需要做限流处理，不然会很卡或者报错
