问题收集篇-限时抢购

之前看来一片大牛的文章，然后总结了下面关于限时抢购的问题
遇到的问题：
1，高并发
比较火热的秒杀的在线人数比较多，如此巨大的在线人数，对于网站的架构从前到后都会是一种巨大的考验。
2，超卖
每个商品都会有数量上限，如何保证成功下订单和购买商品的人的数量不能超过商品本身的库存亮，这是一个问题。

 解决方案：

分开说：
前端：
无非就是三板斧，扩容，静态化，访问限流
1，扩容：通过增加机器，来增加前端池的整体承载量。
2，静态化：将页面展示端所有可以静态化的元素全部静态化，减少动态元素，提高访问/展示效率。
3，限流，一班通过IP级别的限流，来针对某一个IP，对其单位时间内的请求发起的数量进行限制。
4，消峰值，通过在入口处加入游戏，问题等来消去峰值，减少并发访问。
后端-数据库
1，首先高并发会影响MYSQL 的处理性能，开始会随着并发量的增加，处理能力提高，当达到一个峰值点的时候，就会出现一个拐点，之后处理能力一路降低，最后甚至比单线程处理能力都差。
2，超卖问题，归根结底在于减库存操作是一个事务操作，需要先查，然后添加，然后update-1，但是在update-1的时候，如果出现多并发操作，那么不可避免的会出现负数。
3，最后当高并发和超卖碰到一起的时候，那么由于操作库存数量在同一行，那么就会出现争抢DB行锁的问题，导致互相等待甚至死锁的现象，从而大大降低MYSQL的处理能力，最终导致前端出现超时异常。

针对上述问题，如何解决呢？ 先看眼淘宝的高大上解决方案：

　　1： 关闭死锁检测，提高并发处理性能。

　　2：修改源代码，将排队提到进入引擎层前，降低引擎层面的并发度。

　　3：组提交，降低server和引擎的交互次数，降低IO消耗。

总结后端处理方案：
1，缓存+队列的方式（提交操作不分段）
将库存从MYSQL迁移至内存中去，因为内存中不存在锁的机制，所以可以避免锁的问题，另外由于内存的读写操作的速度远高于mysql,所以可以解决高并发下的性能问题，然后引入队列，通过单队列，将所有的DB写操作引入到队列中去，进行串行化处理，当达到库存阈值的时候就不再消费队列，并关闭购买功能，这样就解决了超卖问题。
但是由于是异步的写DB的操作，因此，可能存在某一时刻DB和redis中的数据不一直的问题。

2，将提交操作分为两步执行，先申请，后确认，利用redis的自增和事务特性来发号，保证拿到小于等于库存阈值的用户都能成功购买，然后数据异步写入DB。

总体思路：

1、前端三板斧【扩容】【限流】【静态化】

2、后端两条路【内存】+【排队】

大牛文章引用处：http://www.cnblogs.com/billyxp/p/3701124.html