Java电商秒杀系统性能优化(六)——交易性能优化技术之缓存库存

概述

本篇博客介绍了下单交易的性能优化技术，通过交易验证缓存的优化，库存缓存模型优化解决了交易流程中繁琐耗性能的验证缓存，并解决数据库库存行锁的问题，同时也引入了缓存与数据库分布式提交过程中不一致的风险。

本章的学习目标是：

• 掌握高效交易验证方式
• 掌握缓存库存模型

一、高效交易验证

---

1.1 交易性能瓶颈

• 采用jmeter压测进行性能压测，请求改为POST请求，加入消息体中，average 500ms tps200/s cpu% 75%；
  交易验证完全依赖数据库,通过SQL语句的方式发送给数据库，完成读操作；
• 库存行锁
• 后置处理逻辑
  

1.2 交易验证优化

• 获取用户信息，用户风控策略优化:策略缓存模型化，将对应的风控内容做到redis缓存里面，例如是否异地登录、账号异常，将风控的策略通过异步的方式写入对应缓存中，在实时查询过程中做一个风控策略的实时拦截；
• 活动校验策略优化：引入活动发布流程，模型缓存化，紧急下线能力；
  运营发现活动有异常，在后台将对应的活动进行修改，比如将活动提前结束。若线上在redis的缓存没有正常过期，即便修改了活动时间，但是用户还是可以以活动秒杀价格交易，因此需要一个紧急下线能力。所以运营人员至少要在活动开始前半个小时将活动发布上去，半个小时内足够进行缓存的预热。在后设计一个紧急下线的接口，用代码实现可以清除redis内的缓存。当redis内无法查询状态，就会去数据库内查询活动状态，从而达到紧急下架的能力；

验收效果
jmeter验收验证优化效果
Average time = 600ms tps=1200/s

二、缓存库存模型

2.1 库存行锁优化

itemId需要创建唯一索引

alter table item_stock add unique index
item_id_index(item_id)

2.1.1 扣减库存缓存化

方案：

• 活动发布同步库存进缓存；
• 下单交易减缓存库存；

问题：
数据库记录不一致，缓存中修改了但是数据库中的数据没有进行修改；

2.1.2 异步同步数据库

方案：

• 活动发布同步库存进缓存；
• 下单交易减缓存库存；
• 异步消息扣减数据库内库存；

可以让C端用户完成购买商品的高效体验，又能保证数据库最终的一致性；

2.2 异步消息队列rocketmq

rocketmq：

• 高性能，高并发，分布式消息中间件；
• 典型应用场景：分布式事务，异步解耦；

RocketMQ原理