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

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

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

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

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

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

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

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

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

本文来自Ruesin博客

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

Ruesin.com

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

concurrent

展开阅读全文

没有更多推荐了,返回首页