业务总结002:秒杀活动架构设计

一、秒杀商品模型

二、架构设计

2.1 Redis + MQ

• 缓存预热：秒杀商品一般时效性比较强，一场秒杀活动持续的时间不会很长，当在后台设置秒杀活动添加秒杀商品时，把商品对应的库存直接存到 Redis，但是要注意的是，设置缓存时一定要设置过期时间。
• 削减请求流量：当用户进到秒杀商品详情及后续所有操作都应当进行库存、秒杀资格校验
• 扣减 Redis 库存：当用户从秒杀商品详情到账单页请求下单时，加分布式锁防止用户重复提交请求，等后续校验通过后，扣减 Redis 库存，通过 Redis 保证线程安全，也能保证商品不会超卖，但是此时并不扣减 DB 库存
• 扣减 DB 库存：用户支付核销监听交易支付成功消息，以乐观锁形式扣减 DB 库存。因为只有抢到库存后才能到后续的支付逻辑，一般到秒杀支付逻辑的流量已经很少了，当并发通过乐观锁扣减 DB 库存失败时，消息会重试，保证 Redis 库存与 DB 库存的一致性
• 归还 Redis 库存：用户抢到库存不一定会支付，当用户取消订单或者订单超时未支付时，监听订单取消消息，归还 Redis 库存
• 归还 Redis 与 DB 库存：用户下单支付后请求退款，应当归还 Redis 与 DB 的库存，这里可以考虑监听交易消息，也可以通过交易直调接口的形式处理，因为退款场景比较少，一般不会有很大的流量

这种方式实现起来比较简单，对于流量不是特别大的业务一般够用了，当流量特别大时就需要在上游进行流量控制了，整个过程要考虑是否会出现缓存穿透、缓存雪崩问题。