人人懂点高并发：秒杀系统设计

前端

1，在浏览器端肯定要防止用户重复点击，而且不能使用静态URL，防止内部作弊；

2，一般都是简单网页，商品介绍啥的放在其他常规页面，让客户提前了解即可，专门的秒杀页面用cdn缓存起来；

3，转到机房的NGINX上时，NGINX做出限流配置，例如总并发数肯定不能超过秒杀商品的总数太多；

 

消息队列

1，NGINX过后就到了后端了，第一个就是要查询库存，没有库存了，后续操作没有意义；

2，有库存之后要加入MQ消息队列，把流量高峰削掉；

3，后端微服务从MQ中消费消息；

服务端

方案一，服务端收到请求后，生成订单，订单支付，支付完成后更新库存（redis）

 

方案二，生成订单之后就减库存，在规定的时间内完成支付，没有完成则取消订单，库存增加。

这个可以和放开秒杀的时候分时间段结合起来，例如每5分钟放10w进来。

数据库

1，传统RDBMS，到数据库这一层应该是不能存在问题了，否则系统肯定就宕机了。

2，新思路：

能否把用户，商品，订单状态，支付状态，库存状态都存在redis中？

                  key                                                              value

用户id：商品id为key

几个状态为value，完成的标记为1，未完成的标记为0

例如：zhang:iphone11 ->1 0 0

客户zhang秒杀的iPhone 11完成订单生成，未支付，库存未减

这样完成一轮秒杀后，我们统计状态不需要再查数据库，直接在redis中完成，性能应该能提升。

 

总结：

高并发，秒杀把握的原则只有一条：一层层的过滤掉无效请求就是性能！！！