秒杀问题分析

互联网大潮下，电商汹涌，交易中的秒杀/超卖成了技术人员经常碰到技术问题。

秒杀/超卖首先可以从业务上来解决。比如，先抽奖事后再开奖。如果业务不能避免，那么只能通过技术手段了。

针对核心的库存部分，有这么几种方法。

第一个方式是利用数据库的事务串行和行级锁，辅以正确的sql语句。比如update resource_tbl set  num=num-1 where id=1 AND num>0   

这种方式可以通过应用层的分组队列等，减轻数据层的压力，以便提高性能。参考淘宝丁奇的"秒杀场景下mysql的低效原因和改进"。淘宝有自己定制版的mysql数据库，还可以做到合并提交。可以看看这里(http://blog.csdn.net/jiao_fuyou/article/details/15504777)，他对丁奇的ppt做了一些解释以及可能的方案。

第二个方式是利用先进先出的队列。所有的请求都进入队列，在数据库层面请求是依次处理，先到的能秒成。

第三个方式，考虑到把所有的购买相关步骤(查看 下单 确认购买)移出数据库，只在cache中进行，最后才会更新到数据。这样就需要保证cache如果down了能恢复（比如记日志，不过这种涉及到IO的也会影响性能了）。淘宝有tair，可以做试试。(参考http://wenku.baidu.com/view/fc92f6bdfd0a79563c1e7252.html)

除了库存部分外，对这个问题有综合论述，可以参考"如何解决秒杀的性能问题和超卖的讨论"(http://www.cnblogs.com/billyxp/p/3701124.html)，  【内存】+【排队】，还考虑前端的一些减压措施。比如【扩容】【静态化】【限流】【有损服务】

这个"淘宝秒杀服务器架构猜想"(http://blog.jimeji.com/?p=691)也是不错的参考，他的基本思路是在java后端分层过滤减压。web服务器有多个，每个的servlet里或是业务处理模块，都做一个各自独立的计数（无耦合），超过总数即被过滤；第二层是利用共享的memcache(其有原子操作)的计数，超过总数即被过滤；最后才是app层，实际会如上述的库存管理。

安全起见，秒杀的服务器最好和其他的常规服务分开。

其他可以参考的秒杀文章链接

http://www.chepoo.com/seckill-system-design-and-implementation.html