库存超卖

超卖
恶意请求
链接暴露
数据库 每秒上万甚至十几万的QPS(每秒请求数)

对症下药：

服务单一职责
微服务+分布式部署
下单有订单服务，用户登录有用户服务，开个秒杀服务。订单服务对应订单库，秒杀对应秒杀库。

之后建表，记得用explain看看SQL执行计划。

好处：就算秒杀没抗住秒杀库崩了，服务挂了，也不会影响其他的服务。

Redis集群
单机Redis顶不住，Redis集群，主从同步，读写分离，还搞点哨兵，开启持久化。

Nginx：
Nginx高性能服务器，随便顶几万，虽然Tomcat只能顶几百的并发，负载均衡。‘

资源静态化：
秒杀一般都是特定的商品还有页面模板，前后端分离的，所以页面一般都是不会经过后端的，但是前端也要自己的服务器啊，那就把能提前放入cdn服务器的东西都放进去，反正把所有能提升效率的步骤都做一下，减少真正秒杀时候服务器的压力。

按钮控制：

前端的配合，定时去请求你的后端服务器，获取最新的北京时间，到时间点再给按钮可用状态。按钮可以点击之后也得给他置灰几秒，不然他一样在开始之后一直点的。

限流：

前端限流：这个很简单，一般秒杀不会让你一直点的，一般都是点击一下或者两下然后几秒之后才可以继续点击。

后端限流：秒杀的时候肯定是涉及到后续的订单生成和支付等操作，但是都只是成功的幸运儿才会走到那一步，那一旦100个产品卖光了，return了一个false，前端直接秒杀结束，然后你后端也关闭后续无效请求的介入了。

库存预热：
秒杀的本质，就是对库存的抢夺，每个秒杀的用户来你都去数据库查询库存校验库存，然后扣减库存，撇开性能因数，你不觉得这样好繁琐，对业务开发人员都不友好，而且数据库顶不住啊。

我们要开始秒杀前你通过定时任务或者运维同学提前把商品的库存加载到Redis中去，让整个流程都在Redis里面去做，然后等秒杀介绍了，再异步的去修改库存就好了。

Redis就有一个问题了，我们上面说了我们采用主从，就是我们会去读取库存然后再判断然后有库存才去减库存，正常情况没问题，但是高并发的情况问题就很大了。

就比如现在库存只剩下1个了，我们高并发嘛，4个服务器一起查询了发现都是还有1个，那大家都觉得是自己抢到了，就都去扣库存，那结果就变成了-3，是的只有一个是真的抢到了，别的都是超卖的。咋办？

Lua：
Lua 脚本功能是 Reids在 2.6 版本的最大亮点， 通过内嵌对 Lua 环境的支持， Redis 解决了长久以来不能高效地处理 CAS （check-and-set）命令的缺点， 并且可以通过组合使用多个命令， 轻松实现以前很难实现或者不能高效实现的模式。

Lua脚本是类似Redis事务，有一定的原子性，不会被其他命令插队，可以完成一些Redis事务性的操作。这点是关键。

知道原理了，我们就写一个脚本把判断库存扣减库存的操作都写在一个脚本丢给Redis去做，那到0了后面的都Return False了是吧，一个失败了你修改一个开关，直接挡住所有的请求，然后再做后面的事情嘛。

限流&降级&熔断&隔离：

这个为啥要做呢，不怕一万就怕万一，万一你真的顶不住了，限流，顶不住就挡一部分出去但是不能说不行，降级，降级了还是被打挂了，熔断，至少不要影响别的系统，隔离，你本身就独立的，但是你会调用其他的系统嘛，你快不行了你别拖累兄弟们啊。

削峰填谷：
MQ， 你买东西少了你直接100个请求改库我觉得没问题，但是万一秒杀一万个，10万个呢？

你可以把它放消息队列，然后一点点消费去改库存就好了嘛，不过单个商品其实一次修改就够了，我这里说的是某个点多个商品一起秒杀的场景。

https://www.zhihu.com/search?type=content&q=%E5%BA%93%E5%AD%98%E8%B6%85%E5%8D%96