这次压测会对正向链路中的生订单号、生成订单、预支付、支付回调四个接口做压测，其他接口或逆向接口并发要求不高，所以不做压测。

1、100并发压测4核8G（初步压测，看代码是否有问题）

压测结果：
可以看到，生成订单接口的请求成功率为100%，而提交订单、订单预支付、支付回调接口的成功率都是99.65%，且每个接口的TPS（每分钟处理的事务数）为89左右，其中响应时间比较耗时的是提交订单接口（该接口比较复杂所以很正常）

此时除了生成订单号之外的接口都有失败的情况，我们可以看看具体是什么错误。

1）、先看提交订单接口：

发现是扣减商品库存失败。那这个时候我们去看看数据库的数据是不是真的扣减失败了。

此时就可以知道真的扣减失败了。我们来看下扣减库存时我们的处理是怎么样的。

提交订单接口的逻辑：

1）、入参检查

2）、风控检查

3）、查询数据库，获取商品信息

4）、计算订单价格

5）、验证订单实付金额

6）、生成订单

7）、发送延迟消息用于支付超时自动关单

扣减库存在第6）点，我们看看第6点逻辑：

使用seata AT模式控制下面三个步骤

（1）、锁定优惠券

（2）、扣减库存

（3）、生成订单到数据库

再看看第2步，扣减库存是在AT的模式下，混用TCC模式。看看扣减库存的处理逻辑：

（1）、入参检查

（2）、查询mysql库存数据、查询redis库存数据

（3）、以订单号+sku Id为key做分布式锁防止并发

（4）、查询是否有扣减日志，有则不做重复扣减

（5）、执行库存扣减（TCC模式）

我们可以看到如果扣减失败只能存在第3、5步，先看第三步，第三步的设计是存在问题的，用订单号+sku作为分布式锁的key，此时可以防止同一订单中同一sku的并发问题，可是我们的需求是要做的不同订单的sku的并发问题，所以我们可以初步判断，库存数据错误可能就是分布式锁粒度的问题。此时我们就把key改为sku id再做一次压测。

----------------------------------------------修改完分布式锁key粒度后的压测分析

压测后查看数据：

发现仍然有数据错误，此时我们再去看第（5）步执行库存扣减（TCC模式）。看下处理逻辑

TCC的分支：1、扣减mysql库存  2、扣减redis库存

扣减mysql库存逻辑：

1）、try阶段：执行扣减库存数量

update inventory_product_stock
set sale_stock_quantity = sale_stock_quantity - #{saleQuantity}
where sku_code = #{skuCode}and sale_stock_quantity >= #{saleQuantity}and sale_stock_quantity = #{originSaleStock}

这里只对可售库存做扣减，而没有对已售库存做增加（放在commit阶段，为了模拟数据错乱问题）

2）、commit阶段：增加已售库存，并增加扣减日志

3）、rollback阶段：回滚操作（增加可售库存、删除扣减日志）

此时我们可以看到这里还涉及了另一个表扣减日志表，我们可以顺便看下这个表是否有数据错乱问题：

可以看到，库存数据依然不正确：已销售库存 + 未销售库存 != 总库存 。

并且increase_saled_stock_quantity(代表增加后的已销售库存，应改是10->20->30 递增)值就明显不对了，出现了重复的值。

扣减库存的TCC方案：