高并发下商城秒杀活动的处理

秒杀抢购活动是现在很多商城常见的营销手段，小米抢购、淘宝的整点免单、聚划算等都是成功的例子。

从简单处着手，秒杀是很好理解的：设置要秒杀的商品的数量，抢完为止。但是，实际应用中一瞬间的高并发压力、以及并发带来的负库存是要着重考虑。

要避免负库存的出现，可以在数据库加锁，不管外部多少请求，都可以在数据库操作前给阻断。当然，这种思路可以用在流量不大的普通商品上，用在高并发的秒杀商品上显然是不合适的，直接高频率的读写操作数据库，对数据库的压力太大，严重拖性能，量大的话挂掉也是很有可能的。

Ruesin.com

这时候就需要用到缓存队列了，现在前面应用层处理并发，这个资源的消耗是比较小的，内存中的处理效率也会很快。队列处理完之后再向数据库层进行请求操作。

当然，有时候还有可能会用到文件排他锁，在处理一个订单的时候，使用flock锁定文件，如果锁定失败说明有其他进程正在锁文件处理订单，返回失败。但是只使用这个的话，个人感觉不太好，我宁愿让用户在队列中多等待几秒，也不想直接返回失败。可以在缓存队列到数据库的时候使用下这个，多加一层安全系数。

模拟场景：
商城做一个秒杀活动，秒杀的商品数量为10，秒到即得。

方案：
1、应用层做首次过滤
因为考虑到处理的失败，我们要给缓存开的总数比10稍大是最好的，那我们就给队列开的总数是50。秒杀开始后，我们的队列只接收前面50个请求，当数量满50后，在请求就返回已秒杀完。如果一瞬间的并发大于50，我们就随机取50个放入队列。
缓存的处理是在内存上处理的，效率非常高，但是在这个层面处理过之后要二次请求，可能会有稍许延迟。
2、数据层做二次过滤
从50个中随机或者排序的方式，二次“并发”按队列执行下单，这时候可以考虑使用文件锁。入库时也可考虑使用乐观锁、自定义锁、限制条件等。
经过首次处理后的数据量已经非常小了，直接操作数据库的话压力会小很多，二次过滤也能尽可能的保证数据不超出。
其他：
如果是分布式集群服务器，就需要有一个或多个多层专门的队列服务器，或者配置缓存队列共享。

文章来自ruesin.com

此方案成立的前提是并发量很大，能接近或者超过放出的数量。如果商品库存很足，而且并发量不大，反倒影响了用户体验。

这种二次过滤的架构，下来之后，能最大限度的保证程序的严谨性。

小米和淘宝的抢购还是有稍许不同的，小米重在抢的那瞬间，抢到了名额，就是你的，你就可以下单结算。而淘宝则重在付款的时候的过滤，做了多层过滤，比如要卖10件商品，他会让大于10的用户抢到，在付款的时候再进行并发过滤，一层层的减少一瞬间的并发量。

转载请注明：高并发下商城秒杀活动的处理