1、多个商品的秒杀，可以每个商品对应单独的缓存或者库，这样可以分摊流量，分而治之。
2、很多场景都不是靠性能优化的。而是靠业务优化，比如你说的抢红包，都是“假”抢，你看到的秒杀也是“假”秒。
3、秒杀可以增加预约秒杀，即提前报名，然后秒杀的场景，可以进行多级淘汰。
- 秒杀之前几天，先把“预约”的账号洗一遍，留下预售数量 200%左右的账号，其他账号秒杀当天的请求直接抛弃。
- 秒杀当场，按照请求缓存队列随机枪毙请求，剩下 110%。进入下单流程。
- 最终下单再进行数据库严格校验。锁定账号——货品的对应信息。
4、假秒杀，即用户向后端请求的不是真实的秒杀，或者把默写请求量高的页面的请求屏蔽掉，把流量拦截在外层，降低核心层负载来保证操作的一致性。（返回了一段 JS 动画让部分用户感觉到在参与，通过这个方法降低后端的负载）；
5、商品提前预热、走本地cache
6、先支付创建订单，然后异步下订单，最后同步订单状态到各个系统
7、秒杀增加请求队列，比如商品是1w个，每次放放入1w请求，如果还有库存，在放入1万个，直到库存为0
8、生成动态url，防止恶意用户提前秒杀商品！ 我们应该先在访问秒杀业务时去生成一个动态的url，这样做可以防止恶意用户去通过固定url去提前秒杀商品
9、数学公式验证码，这个也是减少大量请求的方法，因为你要去计算结果，想想几秒钟时间我可以减少多少访问请求，这个数学公司验证码自己去百度找下，同样把生成的验证码结果存储到redis中，判断时在去redis中获取结果对比验证码结果
具体可以提供运营策略，比如让运营或者店家自己选择是哪种方式的“下单锁库存”、“支付成功锁库存”、“发货完成扣库存”秒杀场景：
第一种提前锁库存：下单->锁库存（有超时限制）->支付失败或者超期未支付->释放库存
下单减库存，即当买家下单后，在商品的总库存中减去买家购买数量。下单减库存是最简单的减库存方式，也是控制最精确的一种，下单时直接通过数据库的事务机制控制商品库存，这样一定不会出现超卖的情况。但是你要知道，有些人下完单可能并不会付款。
不会存在库存超卖的情况；
存在恶意锁库存情况；
第二种支付锁库存：下单->支付成功->锁库存
允许少量超卖，支付扣库存即可 - 前提是有备货
付款减库存，即买家下单后，并不立即减库存，而是等到有用户付款后才真正减库存，否则库存一直保留给其他买家。但因为付款时才减库存，如果并发比较高，有可能出现买家下单后付不了款的情况，因为可能商品已经被其他人买走了。
第三种发货锁库存：发货->锁库存
存在库存超卖的情况
最好加上预扣库存预警逻辑
预扣库存，这种方式相对复杂一些，买家下单后，库存为其保留一定的时间（如 10 分钟），超过这个时间，库存将会自动释放，释放后其他买家就可以继续购买。在买家付款前，系统会校验该订单的库存是否还有保留：如果没有保留，则再次尝试预扣；如果库存不足（也就是预扣失败）则不允许继续付款；如果预扣成功，则完成付款并实际地减去库存。
实际库存(商品还没出库的数量), 虚拟库存(商品被购买了,但是还没出库), 锁定库存(有些商家需要预定的或者其他情况),可购库存(可以购买的数量)
实际库存=虚拟库存+锁定库存+可购库存
下订单：减可购库存,+虚拟库存
过时未付款：加可购库存, 减虚拟库存
出库：减虚拟库存, 减实际库存
讨论帖子：
https://www.infoq.cn/article/2017hongbao-weixin
https://www.zhihu.com/question/20978066
https://www.v2ex.com/t/703857
https://www.v2ex.com/t/673266
https://www.v2ex.com/t/691526
https://www.infoq.cn/article/2017hongbao-weixin
https://blog.csdn.net/qq_34802511/article/details/81296097