我们对于交易进行一下200个线程压测,看下应用服务器的资源:
再看下压测结果:
接下来用1000个线程看下数据库资源:
并且耗时也加大了:
那么对于下单我们一般会有几个步骤:1.校验商品是否存在,用户是否合法,购买数量是否正确。2.落单减库存。3.订单入库,加商品销量。4.返回前端。
通过上面步骤,其实我们对于数据库至少有6次操作,而且在减数据库的时候是根据id操作,那还有个行锁,所以性能亟待优化。
交易验证的优化,可以分为两部分:
用户风控策略优化:策略缓存模型化
活动校验策略优化:引入活动发布流程,模型缓存化,紧急下线的能力
例如我们把产品信息放到redis中(用户信息一样):
@Override
public ItemModel getItemByIdInCache(Integer id) {
ItemModel itemModel = (ItemModel) redisTemplate.opsForValue().get("item_validate_"+id);
if (itemModel == null){
itemModel = this.getItemById(id);
redisTemplate.opsForValue().set("item_validate_"+id , itemModel);
redisTemplate.expire("item_validate_"+id , 10 , TimeUnit.MINUTES);
}
return itemModel;
}
压测一下
区别不太大的原因是服务器带宽问题,但是还是有提升。
对于紧急下架功能,我们可以开放一个接口,删除redis即可。
对于库存行锁的优化:
扣减库存缓存化
异步同步数据库
库存数