一、秒杀带来了什么？
这个环节是最考验业务提供方的抗压能力的。
抢订单环节一般会带来2个问题：
1、高并发
比较火热的秒杀在线人数都是10w起的，如此之高的在线人数对于
任何商品都会有数量上限，如何避免成功下订单买到商品的人数不
首先，产品解决方案我们就不予讨论了。我们只讨论技术解决方案
1、前端
A：扩容
加机器，这是最简单的方法，通过增加前端池的整体承载量来抗峰值。
将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。
C：限流
一般都会采用IP级别的限流，即针对某一个IP，限制单位时间内发起请求数量。
或者活动入口的时候增加游戏或者问题环节进行消峰操作。
D：有损服务
最后一招，在接近前端池承载能力的水位上限的时候，随机拒绝部分请求来保护活动整体的可用性。
2、后端
那么后端的数据库在高并发和超卖下会遇到什么问题呢？
主要会有如下3个问题：（主要讨论写的问题，读的问题通过增加cache可以很容易的解决）
针对上述问题，如何解决呢？ 我们先看眼淘宝的高大上解决方案：
I： 关闭死锁检测，提高并发处理性能。
II：修改源代码，将排队提到进入引擎层前，降低引擎层面的并发度。
III：组提交，降低server和引擎的交互次数，降低IO消耗。
解决方案1：
不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发
下的性能问题。然后通过队列等异步手段，将变化的数据异步写入到DB中。
优点：解决性能问题
缺点：没有解决超卖问题，同时由于异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。
就不在消费队列，并关闭购买功能。这就解决了超卖问题。
优点：解决超卖问题，略微提升性能。
缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，
解决方案3：
将写操作前移到MC中，同时利用MC的轻量级的锁机制CAS来实现减库存操作。
优点：读写在内存中，操作性能快，引入轻量级锁之后可以保证同一时刻
缺点：没有实测，基于CAS的特性不知道高并发下是否会出现大量更新失败？
解决方案4：
自增来说没有空洞），同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人都
可以成功提交订单。然后数据异步更新到DB中。
优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。
缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人
来源：博客园
作者：changyu521
链接：https://www.cnblogs.com/changyu521/p/11765575.html