内存的数据操作时间为纳秒级别，而一次SSD盘数据访问在几十微妙，SATA盘在几十毫秒，可以看出内存和磁盘IO上存在量级的差异。所以在对性能有高要求的系统中，一般都采用缓存（大多缓存实现都是基于内存处理的）将数据load进内存中，提高处理率和吞吐。尤其是高并发量的电商秒杀业务。那秒杀又分为小库存商品秒杀和大库存商品秒杀，例如100台3c产品和1w带洗衣液。下面分别对两种秒杀类型在缓存使用上进行分析。
小库存秒杀
例如10个库存，商品会在极短的时间内库存降至0，所以关键在于处理好商品库存减扣，不要出现超卖即可。
关键点：
1、秒杀商品与普通商品的商品中心实例应该视情况考虑是否分开隔离部署，避免秒杀访问量对整个商品中心服务受影响
2、秒杀页面即商品的详情页，大量用户停留刷新，如果每次刷新都从DB获取数据，势必造成db压力。
方案：将商品详情页和库存信息缓存起来，直接访问缓存服务。用户成功付款后，修改db库存，然后修改缓存。（笔者理解，db减库存和缓存同步不应放到一个事务里，db是一定要修改成功的。为防止db减库存成功后同步缓存失败问题，从设计上，可以通过接口或异步mq的重试或消息必达机制对来处理缓存减库存）（db与缓存数据同步）
3、商品上架问题，8点秒杀，提前或滞后都不行（提前售空或用户体验差）。定时任务控制商品上架+请求时间判断控制，早于8点请求不予执行。
4、避免超卖，商品库存采用乐观锁处理。（版本号、时间戳对比，另外还可通过在更新时，对比更新事务执行前获取的库存量与当前db中库存量，如果一致，则执行更新。不一致说明已做修改，可采用重试重新执行更新事务）
流程：
1、秒杀时，用户查看商品详情及库存量--读缓存
2、尚有库存，购买，下单页中展示商品详情--读缓存
3、下单完成后，db获取当前商品真实库存，若>0,进行扣减，更新db成功后，更新缓存中商品库存。前端用户访问即为更新后的库存。
大库存秒杀
例如1w带洗衣液，库存记录只有一条，采用上面更新是数据对比，而后更新缓存，在整个操作中其他请求等待，上一个减库存操作返回成功才能进行下一个用户的购买处理。导致用户长时间创建订单等待，可能后点创建订单的客户反而比前面提交的用户提前下单成功。
所以，大库存秒杀业务下，缓存除了load详情页和库存信息之外，还可采用缓存来支持减库存事务操作。
1、秒杀开始前，商品库存加载到缓存中
2、详情页同样读取缓存
3、用户点击确认购买进行下单操作时，后台创建订单详情记录（落库），不过在库存扣减成功前，该订单详情对用户不可见。（保存订单信息，用作缓存崩溃时，通过初始数据还原订单处理的最新状态），类似于上文大事务拆分中，支付宝-余额宝交易中转账流水表一个作用，避免缓存故障造成业务数据损失。
4、db中创建订单详情成功，发送库存减库存消息（mq），缓存中库存更新成功后，修改订单详情表状态为下单成功。 直接将缓存当db，利用缓存读写比db io快提高性能，利用缓存来减库存。