8.交易方面的优化，redis和rocketmq

我们对于交易进行一下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即可。

 

对于库存行锁的优化：

扣减库存缓存化

异步同步数据库

库存数