如何设计一个秒杀系统

前言

其实秒杀系统可以看成是现实系统的一个升级版，也可以说是对平时所有技术的一个高效的、综合的运用，下面简单看下之前做过的一个基于redis+mysql的一个简单秒杀流程

上面这种其实适用于一些秒杀用户量和奖品都不是很多的情况，如果用户量特别大的情况，可能就需要更加复杂的设计了。

正文

其实上面的方案中减库存虽然使用库存量大于0作为条件，但是对于并发超过500，访问量超过2000依然可能会存在超卖的现象的（当然上面的限流器其实已经解决了并发量的问题），针对超卖可以使用mysql的乐观锁来解决，加一个版本的字段，每次更新之后版本号加1，也可以使用redis队列来缓存奖品标识，当用户抢到一个商品，就从redis中删除该奖品标识等等。那么扣减库存有以下几种方式

• 下单减库存。 即当买家下单后，在商品的总库存中减去买家购买数量。下单减库存是最简单的减库存方式，也是控制最精确的一种，下单时直接通过数据库的事务机制控制商品库存，这样一定不会出现超卖的情况。但是你要知道，有些人下完单可能并不会付款。一般适用于一些兑换，不用真正付款的小型秒杀系统。但是可能出现手恶意抢购商品后退单情况。
• 付款减库存。 即买家下单后，并不立即减库存，而是等到有用户付款后才真正减库存，否则库存一直保留给其他买家。但因为付款时才减库存，如果并发比较高，有可能出现买家下单后付不了款的情况，因为可能商品已经被其他人买走了。能够防止对手恶意抢购商品后退单，但是不常用，并且相对复杂。用户体验相对差。
• 预扣库存。 这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 10 分钟），超过这个时间，库存将会自动释放，释放后其他买家就可以继续购买。在买家付款前，系统会校验该订单的库存是否还有保留：如果没有保留，则再次尝试预扣；如果库存不足（也就是预扣失败）则不允许继续付款；如果预扣成功，则完成付款并实际地减去库存。适用于大型秒杀系统，性能好，用户体验较好。
   

另外可以使用异步队列解耦的方式，先将抢购成功的用户信息放入队列中慢慢处理，还有分布式限流，nginx过载保护、服务降级、限流等。

后记

技术是服务于业务的，不管使用什么样的技术，适合的才是最好的，同时也要结合公司具体使用情况，但是总体的思路围绕着几点来考虑：

1. 更新库存保证不超卖
2. 分布式限流保证服务器不宕机 
3. Redis 缓存保证处理效率 
4. 异步处理，解耦高效提高用户体验

 资料：https://blog.csdn.net/qq_42046105/article/details/93148445

https://blog.csdn.net/libra_ts/article/details/85198469