前端
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中完成，性能应该能提升。
总结：
高并发，秒杀把握的原则只有一条：一层层的过滤掉无效请求就是性能！！！
