解决超卖思路

一、　经验教训

1、高并发

活动开始时，对于并发的处理需要架构从前到后的配合。

　　2、超发

奖品都会有数量上限，因此如何避免超发是要面临的又一个难题。

 

二、解决方案

1、前端

　　A：扩容

　　加机器，这是最简单的方法，通过增加前端池的整体承载量来抗峰值。

　　B：静态化

　　将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素。通过CDN来抗峰值。

　　C：限流

　　一般都会采用IP级别的限流，即针对某一个IP，限制单位时间内发起请求数量。

　　D：有损服务

　　最后一招，在接近前端池承载能力的水位上限的时候，随机拒绝部分请求来保护活动整体的可用性。

 

2、后端

A：所有的读写操作放到内存中

B:使用队列解决超发

队列方案一:按奖品数生成队列：（奖品数较少情况适用）

　　引入队列，然后将所有写DB操作在单队列中排队，完全串行处理。当达到库存阀值或活动时间结束的时候就不在消费队列，活动结束

　　优点：解决超发问题，略微提升性能。

缺点：性能受限于队列处理机处理性能和DB的写入性能中最短的那个，另外多商品同时抢购的时候需要准备多条队列。

队列方案二: FIFO队列（奖品数多适用）：

我们直接将请求放入一个队列中的，采用FIFO（First Input First Output，先进先出）。

 

优点：解决超发问题

缺点：高并发的场景下，因为请求很多，很可能一瞬间将队列内存“撑爆”，然后系统又陷入到了异常状态，需设计一个极大的内存队列