1. [秒杀]抢订单环节一般会带来2个问题：
1.高并发：大量用户同一时间抢购，网站瞬时访问量剧增，导致服务器压力大
2.超卖: 成功下订单买到商品的人数，超过数据库最大库存数量
2. [秒杀]解决方案：
前端 [扩容，静态化，限流]：
A扩容：
加机器，这是最简单的方法，通过增加前端池的整体承载量来抗峰值。
B：静态化
将页面能够静态化的元素全部静态化，并减少动态元素，通过CDN来抗峰值
ESI: 在web服务器上做动态内容请求，并将数据插入静态页面中，用户拿到就一个完整的页面，这种方案对服务器端性能有影响，但是用户体验好
CSI：在静态页面中单独发送异步js请求，从服务器动态获取数据，这种服务器效果很好，但是用户体验稍差
C：限流
ip限流：针对某一个ip地址，限制单位时间内访问次数
D：其他
在活动入口的地方设置关卡游戏或者问题环节，削弱峰值
后端出现高并发和超卖的原因：
I： 首先MySQL自身对于高并发的处理性能就会出现问题，一般来说，MySQL的处理性能会随着并发thread上升而上升，但是到了一定的并发度之后会出现明显的拐点，之后一路下降，最终甚至会比单thread的性能还要差。
II： 其次，超卖的根结在于减库存操作是一个事务操作，需要先select，然后insert，最后update -1。最后这个-1操作是不能出现负数的，但是当多用户在有库存的情况下并发操作，出现负数这是无法避免的。
III：最后，当减库存和高并发碰到一起的时候，由于操作的库存数目在同一行，就会出现争抢InnoDB行锁的问题，导致出现互相等待甚至死锁，从而大大降低MySQL的处理性能，最终导致前端页面出现超时异常。
解决方案1：
将存库从MySQL前移到Redis中，所有的写操作放到内存中，由于Redis中不存在锁故不会出现互相等待，并且由于Redis的写性能和读性能都远高于MySQL，这就解决了高并发下的性能问题。然后通过队列等异步手段，将变化的数据异步写入到DB中。
优点：解决性能问题
缺点：没有解决超卖问题，同时由于异步写入DB，存在某一时刻DB和Redis中数据不一致的风险。
解决方案2：
引入队列，然后将所有写DB操作在单队列中排队，完全串行处理。当达到库存阀值的时候就不在消费队列，并关闭购买功能。这就解决了超卖问题。
优点：解决超卖问题，略微提升性能。
缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，另外多商品同时抢购的时候需要准备多条队列。
解决方案3：
将写操作前移到Memcached中，同时利用Memcached的轻量级的锁机制CAS来实现减库存操作。
优点：读写在内存中，操作性能快，引入轻量级锁之后可以保证同一时刻只有一个写入成功，解决减库存问题。
缺点：没有实测，基于CAS的特性不知道高并发下是否会出现大量更新失败？不过加锁之后肯定对并发性能会有影响。
解决方案4：
将提交操作变成两段式，先申请后确认。然后利用Redis的原子自增操作（相比较MySQL的自增来说没有空洞），同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人都可以成功提交订单。然后数据异步更新到DB中。
优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。
缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值
服务器解决性能瓶颈问题
1.排队：
可以使用消息队列，将同步请求转化成异步请求，中间通过一个消息队列在一端[队列入口]承接瞬时的流量峰值，在另一端[队列出口]平滑的将消息推送出去
2.设置关卡：
在活动入口的地方设置关卡游戏或者问题环节，削弱峰值
3.分层过滤：
秒杀请求先经过CDN ==> 前端系统 ==> 后端系统 过滤掉无效请求
