高并发电商秒杀的演进-优快云博客

没有最好的架构，只有最合适的架构。秒杀作为电商很重要的一部分，其技术实现也是相对比较复杂的。随着秒杀用户的增加，架构也是随之改变的，当然也可以一次性设计好，但是我并不建议这么做。为什么呢？大部分互联网公司初创时的人员非常少，有经验的更是稀缺，这时候如果一上来就往千万级，亿级的并发量设计，其难度可想而知。可能你花了一年，两年甚至更久的时间，系统还不能稳定，而此时公司的资源早已被耗尽，所设计的架构还没来得及接受市场的考验，就要夭折了，更有甚者，公司直接倒闭，这在当今互联网已经是很常见的了。所以建议大家在设计架构时综合考虑一下。好了，下面就来说说高并发电商架构的演进之路吧。我把它分成了三种架构，供大家一起学习探讨，如有错误，欢迎大家批评指正。

1、直接使用分布式锁方式。

分布式锁不仅限下图所指出的redis，还可以是zookeeper, 数据库的乐观锁，悲观锁（一锁二查三更新），如有不清楚的大家可以自行百度。下面来看看这种模式的架构图。

这种架构对于一般的小型公司，并发量不大的情况下是相当适合的。该系统的瓶颈在于获取redis的锁，处理业务，最后释放锁这一块。当请求量剧增时，大量请求必然在获取redis锁那里阻塞，最后会导致处理超时。那么这样如果遇到了请求量剧增的业务场景时怎么解决呢？来看看第二种架构。

2、排队＋分布式锁方式

相对于第一种和第三种方式，这种方式算是一种折中的解决方案。下面是它的架构图

这种方式相对于第一种方式来说增加了一个排队队列。如果排队人数大于库存量，可以直接将该信息返回给用户。其它请求就不会进入减少库存的业务服务器，这样对于减小库存的业务服务器的压力来说是一种非常有效的手段。相信大部分人都用过12306，估计有很多人对它有很大意见，因为在抢回家的票时经常会遇到 “未出票,订单排队中... 最新预估等待时间为20 分钟” 这样的情况。其实这也不能怪12306，毕竟很多人分析过，12306的复杂程度，远超淘宝等电商，而且它也没有那么多的技术人员。

从用户体验的角度，大家想想这种方式相对于第一种方式的好处是什么呢？假设你是一个产品经理，那么这个时候你需要关注两种人群，第一种就是秒杀成功（也就是抢票成功的用户），第二种就是秒杀不成功（也就是抢票失败的用户）。那么你更应该关注那种人的感受呢？毫无疑问是第二种人群（秒杀失败的用户）。对于秒杀失败的用户来说，如果使用第一种架构，很可能会出现这种情况，等了几分钟，鼠标都快点废了，最后返回一个网络超时或者秒杀失败。你想想这个时候，他们的第一反应肯定是“草泥马的，这是什么垃圾网站，下次再也不用了”。很可能，公司就与这个用户无缘了。那我们再来看看第二种架构好在哪里，当用户由于网络原因，或者手速原因慢的时候，没有进入排队队列，这时候直接给用户返回了，让用户无需多等，当然这时候返回也比平常慢，因为cpu处理大量网络请求时有性能瓶颈，即使这样相对于还要进行秒杀业务处理来说，这个时间已经很小了。

上面主要是从秒杀失败人群来分析的，下面从秒杀成功的人来分析下。大家秒杀成功之后会做什么呢，当然是在30分钟内支付。很多时候支付处理和秒杀处理在同一服务器，那么之前大量的请求必然会消耗服务器的资源，导致支付也会受到影响。如果用户秒杀成功，但是支付失败了，这种情况估计一万个草泥马都不解气吧。

说到这里我也来分析一下，12306为什么排队时间有时会越来越长，以下只是猜测，不一定正确，不喜勿喷。个人猜测12306排队队列大小肯定大于总票数，当用户进入了排队队列，然而余票已经售完的时候，系统很可能在等待没有支付的人退票，如果排队用户前面接二连三的有这种没有支付的人的话，等待时间自然很长。

12306可以使用这种方式，因为它是铁老大，在用户面前它是爹，当然还有很多的游戏也是采用这种方式来处理高并发的。但是如果作为一个普通的电商平台，这种体验不好的操作估计没多少公司敢做。所以又有了下面的第三种架构模式。

3、分布式数据处理

这种模式主要是有n个子系统，每个系统处理一部分数据，比如第一个子系统处理库存号从（1-99），第二个处理库存号100-199，... ,一直到第n个子系统。这个首先要做的就是库存要分库，各个子系统可按第一种或第二种模式进行设计，需要的服务器相对来说要多的多。下面是其架构图