秒杀系统设计
1.秒杀系统的特点
瞬时高并发
2.预防措施
2.1.流量限制
- 对于一个相同的用户，限制请求的频次
- 对于一个相同的IP，限制请求的频次
- 验证码，减缓用户请求的次数
- 活动开启之前，按钮先置灰，防止无效的请求流入系统，给系统造成冲击
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,2,3]，第二次可能是[3,1,2]
- 每次扣减子库存的请求，就会分布到不同的 Redis 分片上，缓轻 Redis 单分片压力的同时，也能支持更高 QPS 的扣减请求
这种思路的一个问题是，当库存接近耗尽的情况下，很多分片子库存的轮询将变得毫无意义===> 因此可以在每次请求的时候，将子库存的剩余量记录下来，当某一个券模板的子库存耗尽后，随机不重复的轮询操作直接跳过这个子库存分片，这样能够优化系统在库存即将耗尽情况下的响应速度。
方案2：本地缓存
本地缓存，保存Redis中的库存数据。当秒杀时，先查询本地缓存，如果数据秒杀没了，就不会再请求到Redis了
分析：这里存在一个问题，引入了本地缓存，那么本地缓存和Redis缓存存在数据一致性问题，怎么解决呢？
答：定时器，查询完成单量的库存，更新到Redis和本地缓存中（矫正）