北京电商网站建设哪家好,有哪些网站制作公司,宿迁百度seo,最火爆的国际贸易网站这次压测会对正向链路中的生订单号、生成订单、预支付、支付回调四个接口做压测#xff0c;其他接口或逆向接口并发要求不高#xff0c;所以不做压测。
1、100并发压测4核8G#xff08;初步压测#xff0c;看代码是否有问题#xff09;
压测结果#xff1a;可以看到其他接口或逆向接口并发要求不高所以不做压测。
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方案 try阶段扣减销售库存 commit阶段 增加已销售库存记录库存更新⽇志。 rollback阶段增加销售库存删除库存更新⽇志 第一个问题 库存减扣⽇志不正确的问题原因 因为commit阶段是有Seata Sever来触发的是异步的 举个例⼦ 有两个订单order1 和order 2 同时串⾏减扣sku 1 库存, 假设sku 1 的销售库存 1000 已销售 库存0 . 假设order1 和order 2 竞争锁order 1 获取了锁成功order 1 查询到的已销售库存为 0 。order 1 减掉销售 库存就结束释放了锁然后由seata在异步的去增加已销售库存由0 - 1 , 假设此时seata server还没 有调⽤到commit⽅法此时order 2 的请求过来了查询到的已销售库存为 0 然后order 2 在commit阶段更新已销售库存还是0 - 1 由此出现了上⾯的⽇志不正确的问题 第二个问题 库存数据不正确的问题原因是因为commit阶段是异步的 增加销售库存使⽤了乐观锁 try阶段扣减可售库存时sql加了sale_stock_quantity #{originSaleStock}条件 和前⾯例⼦⼀样commit阶段是异步的在commit阶段order 1 要更新已销售库存 0 - 1 ,order 2 要更新的已销售库存0 - 1 和上⼀个例⼦⼀样 第二个问题解决去掉sql中sale_stock_quantity #{originSaleStock}条件 第一个问题解决 1、将保存库存更新⽇志的逻辑 从 commit阶段移动到 try阶段 将product_stock_log的插⼊从LockMysqlStockTccServiceImpl 的commit⽅法移动到放在LockMysqlStockTccServiceImpl.deductStock()⽅法中日志插入从commit阶段移动到try阶段 2、 库存扣减⽇志的原始已销售库存字段需要从上⼀笔最后一笔库存扣减⽇志获取 不能从库存表拿数据并发时取到的数据是错误的导致插入的日志数据也是错的所以我们会将日志插入操作放到try阶段try完成后会将最新的库存数据保存到扣减日志表中我们去扣减日志表中直接拿最新的库存日志即可 3、考虑回滚时日志要如何操作原先的逻辑是 rollback操 作会删除库存减扣⽇志会导致库存减扣⽇志数据不正确。 该问题未修复 即A执行try做了日志插入后发生异常10-20此时进行rollback操作还没回滚完(20-10)B则去执行try去获取日志表数据(20-30)获取完后A就做完回滚了(A的日志被删除了)B执行成功则作日志插入20-30,而正常情况下最后一条数据在A、B执行完后应该是20。 此时我们只能做到大部分数据不错误即保证后面的数据不错乱此时将回滚操作的删除日志修改为修改日志操作修改最后一条数据,即将30-20虽然这样A的日志还是错的但此时C进来做交易的时候取到的日志是对的 此时再做压测发现数据都正常了。同样的道理redis也会存在库存数据错乱的情况此时和mysql类似处理即可redis没有日志错乱问题只有库存数据错乱问题
