秒杀系统设计

1.秒杀系统的特点

瞬时高并发

2.预防措施

2.1.流量限制

1. 对于一个相同的用户，限制请求的频次
2. 对于一个相同的IP，限制请求的频次
3. 验证码，减缓用户请求的次数
4. 活动开启之前，按钮先置灰，防止无效的请求流入系统，给系统造成冲击

2.2.页面静态化（活动开始前）

分析：

• 活动页面是用户流量的第一入口，所以是并发量最大的地方。
• 如果这些流量都能直接访问服务端，恐怕服务端会因为承受不住这么大的压力，而直接挂掉。

 

活动页面绝大多数内容是固定的，比如：商品名称、商品描述、图片等。为了减少不必要的服务端请求，通常情况下，会对活动页面做静态化处理。用户浏览商品等常规操作，并不会请求到服务端。只有到了秒杀时间点，并且用户主动点了秒杀按钮才允许访问服务端。

2.3.CDN（内容分发网络）

用户分布在全国各地，有些人在北京，有些人在成都，有些人在深圳，地域相差很远，网速各不相同。

如何才能让用户最快访问到活动页面呢？答：使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

3.扣减库存方案选型

下单、支付、减库存

3.1.下单减库存

• 即当买家下单后，在商品的总库存中减去买家购买数量。

下单减库存是最简单的减库存方式，也是控制最精确的一种，下单时直接通过数据库的事务机制控制商品库存，这样一定不会出现超卖的情况。但是你要知道，有些人下完单可能并不会付款。

弊端：如果有竞争对手通过恶意下单的方式将该卖家的商品全部下单，让这款商品的库存减为零，那么这款商品就不能正常售卖了。要知道，这些恶意下单的人是不会真正付款的，这正是“下单减库存”方式的不足之处。

3.2.付款减库存

• 即买家下单后，并不立即减库存，而是等到有用户付款后才真正减库存，否则库存一直保留给其他买家。

“付款减库存”又会导致另外一个问题：库存超卖。

弊端：假如有 100 件商品，就可能出现 300 人下单成功的情况，因为下单时不会减库存，所以也就可能出现下单成功数远远超过真正库存数的情况，这尤其会发生在做活动的热门商品上。这样一来，就会导致很多买家下单成功但是付不了款，买家的购物体验自然比较差

3.3.预扣库存

• 买家下单后，库存为其保留一定的时间（如 10 分钟），超过这个时间，库存将会自动释放，释放后其他买家就可以继续购买。

Q：这种方案确实可以在一定程度上缓解上面的问题。但是否就彻底解决了呢？

A：其实没有！针对恶意下单这种情况，虽然把有效的付款时间设置为 10 分钟，但是恶意买家完全可以在 10 分钟后再次下单，或者采用一次下单很多件的方式把库存减完。针对这种情况，解决办法还是要结合安全和反作弊的措施来制止。

4.方案详解

MYSQL

• 单个 MySQL 的每秒写入在 4000 QPS 左右，超过这个数字，MySQL 的 I/O 时延会剧量增长。
• MySQL 单表记录到达了千万级别，查询效率会大大降低，如果过亿的话，数据查询会成为一个问题。

Redis

• Redis 单分片的写入瓶颈在 2w 左右，读瓶颈在 10w 左右

4.1.预扣库存

4.1.1.分布式事务（扣库存+支付）

        如何保证分布式事务：扣库存、支付：rocketmq事务消息

4.1.2.热key（库存key）

库存这个key的访问是非常大的，是一个热key，由于Redis单机性能10w，因此，可能会被拖垮

方案1： Redis分片

将库存key，分成多个key，打散存在不同的分片上，比如xxx_stock_key1、xxx_stock_key2、...

扣减库存的过程：

1. 先生成对应分片总数的随机不重复数组，如第一次是[1,2,3]，第二次可能是[3,1,2]
2. 每次扣减子库存的请求，就会分布到不同的 Redis 分片上，缓轻 Redis 单分片压力的同时，也能支持更高 QPS 的扣减请求

        这种思路的一个问题是，当库存接近耗尽的情况下，很多分片子库存的轮询将变得毫无意义===> 因此可以在每次请求的时候，将子库存的剩余量记录下来，当某一个券模板的子库存耗尽后，随机不重复的轮询操作直接跳过这个子库存分片，这样能够优化系统在库存即将耗尽情况下的响应速度。

方案2：本地缓存

本地缓存，保存Redis中的库存数据。当秒杀时，先查询本地缓存，如果数据秒杀没了，就不会再请求到Redis了

分析：这里存在一个问题，引入了本地缓存，那么本地缓存和Redis缓存存在数据一致性问题，怎么解决呢？

答：定时器，查询完成单量的库存，更新到Redis和本地缓存中（矫正）