秒杀场景的特点是短时间、高并发，业务系统要处理瞬时的大量高并发请求，而Redis

的高性能特性就经常被用来支撑秒杀活动。

根据我们的购物体验，我们可以把秒杀场景分为三个阶段，第一个阶段是秒杀前，我们

一般都会在活动开始前就进到页面刷新，这时候我们的商品详情页面的流量会激增，

所以我们通常会把这个页面静态化，通过浏览器缓存或者cdn把静态页面缓存起来，

以此来缓解服务端压力。

第二个阶段是活动开始的时候，会有大量请求到达服务端，先是查询库存，库存足够，

扣减库存，下单进而订单处理，如果库存不够则返回。压力最大的时候是查询库存的

时候，通常会使用redis来进行库存的查询及库存扣减操作，并不会在数据库端做库存扣减操

作，首先因为数据库相较而言比较慢，而且还得进行数据库与redis的数据同步，容易因为

数据更新慢而导致商品超卖情况，查询库存及库存扣减操作，必须保证其原子性。

第三个阶段是订单后续处理，物流、供应链、退单等等情况，这个阶段是请求量较小，

普通服务端基本能满足。

高并发

商品秒杀是典型的高并发场景，redis本身的特性足以满足并发要求，需要注意的是，如果

商品较多的情况下，我们可以把这些商品分布在不同的切片实例上，避免秒杀请求集中在

少量实例上，我们需事先通过crc计算好各商品的key对应的slot，然后合理的把slot分配

到实例上。

查询库存及扣减库存的原子性

我们必须保证查询库存及扣减库存在同一请求下的原子性执行，不然库存就乱套了，我们

可以之间使用redis的原子性操作，因为查询库存和扣减库存是两条命令，所以我们得依赖

lua脚本以完成原子性操作。

另一个方案则是通过分布式锁来保证多客户端的互斥性，请求会先访问锁的实例，得到

锁之后，再执行后续查询库存及扣减库存操作，建议把锁和库存放在不同实例上。