时间回到2011年底。小米公司在这一年8月16日首次发布了手机,立刻引起了市场轰动。随后,在一天多的时间内预约了30万台。之后的几个月,这30万台小米手机通过排号的方式依次发货,到当年年底全部发完。
然后便是开放购买。最初的开放购买直接在小米的商城系统上进行,但我们那时候完全低估了“抢购”的威力。瞬间爆发的平常几十倍流量迅速淹没了小米网商城服务器,数据库死锁、网页刷新超时,用户购买体验非常差。
市场需求不等人,一周后又要进行下一轮开放抢购。一场风暴就等在前方,而我们只有一周的时间了,整个开发部都承担着巨大的压力。
小米网可以采用的常规优化手段并不太多,增加带宽、服务器、寻找代码中的瓶颈点优化代码。但是,小米公司只是一家刚刚成立一年多的小公司,没有那么多的服务器和带宽。而且,如果代码中有瓶颈点,即使能增加一两倍的服务器和带宽,也一样会被瞬间爆发的几十倍负载所冲垮。而要优化商城的代码,时间上已没有可能。电商网站很复杂,说不定某个不起眼的次要功能,在高负载情况下就会成为瓶颈点拖垮整个网站。
这时开发组面临一个选择,是继续在现有商城上优化,还是单独搞一套抢购系统?我们决定冒险一试,我和几个同事一起突击开发一套独立的抢购系统,希望能够绝境逢生。
HTTP服务层主要功能如下:
-
进行基本的URL正确性校验;
-
对恶意访问的用户进行过滤,拦截黄牛;
-
提供用户验证码;
-
将正常访问用户数据放入相应商品队列中;
-
等待业务处理层返回的处理结果。
业务处理层主要功能如下:
-
接收商品队列中的数据;
-
对用户请求进行处理;
-
将请求结果放入相应的返回队列中。
用户的抢购请求通过消息队列,依次进入业务处理层的Go进程里,然后顺序地处理请求,将抢购结果返回给前面的HTTP服务层。
商品剩余数量等信息,根据商品编号分别保存在业务层特定的服务器进程中。我们选择保证商品数据的一致性,放弃了数据的分区容忍性。
技术方案需要依托具体的问题而存在。脱离了应用场景,无论多么酷炫的技术都失去了价值。