订阅程序员杂志RSS CSDN首页> 程序员杂志

“米粉节”背后的故事——小米网抢购系统开发实践

发表于2014-11-07 16:53| 次阅读| 来源《程序员》| 0 条评论| 作者韩祝鹏

摘要:今年4月的“米粉节”对小米网来说意义非凡,是其彻底重构后迎来的一次全面压力测试,涉及网站前端、后台系统、仓储物流、售后等各环节。高并发的负载能力、稳定性、准确性等已不是问题,灵活性与可运营性成为关键。

2014年的米粉节

2014年4月9日凌晨,我和同事们对小米网的抢购系统做了最后的检查与演练。几个小时后,小米网今年开年来最重要的一次大型活动“米粉节”就要开始了。

这次米粉节活动,是小米电商的成人礼,是一次重要的考试。小米网从网站前端、后台系统、仓储物流、售后等各个环节,都将接受一次全面的压力测试。

10点整,一波流量高峰即将到来,几百万用户将准点挤入小米网的服务器。而首先迎接压力冲击的,就是挡在最前面的抢购系统。

而这个抢购系统是重新开发、刚刚上线不久的,这是它第一次接受这样严峻的考验。

系统能不能顶住压力?能不能顺畅正确地执行业务逻辑?这些问题不到抢购高峰那一刻,谁都不能百分百确定。

9点50分,流量已经爬升得很高了;10点整,抢购系统自动开启,购物车中已经顺利加入了抢购商品。

一两分钟后,热门的抢购商品已经售罄自动停止抢购。抢购系统抗住了压力。

我长舒一口气,之前积累的压力都消散了。我坐到角落的沙发里,默默回想抢购系统所经历的那些惊心动魄的故事。这可真是一场很少人有机会经历的探险呢。

抢购系统是怎样诞生的

时间回到2011年底。小米公司在这一年8月16日首次发布了手机,立刻引起了市场轰动。随后,在一天多的时间内预约了30万台。之后的几个月,这30万台小米手机通过排号的方式依次发货,到当年年底全部发完。

然后便是开放购买。最初的开放购买直接在小米的商城系统上进行,但我们那时候完全低估了“抢购”的威力。瞬间爆发的平常几十倍流量迅速淹没了小米网商城服务器,数据库死锁、网页刷新超时,用户购买体验非常差。

市场需求不等人,一周后又要进行下一轮开放抢购。一场风暴就等在前方,而我们只有一周的时间了,整个开发部都承担着巨大的压力。

小米网可以采用的常规优化手段并不太多,增加带宽、服务器、寻找代码中的瓶颈点优化代码。但是,小米公司只是一家刚刚成立一年多的小公司,没有那么多的服务器和带宽。而且,如果代码中有瓶颈点,即使能增加一两倍的服务器和带宽,也一样会被瞬间爆发的几十倍负载所冲垮。而要优化商城的代码,时间上已没有可能。电商网站很复杂,说不定某个不起眼的次要功能,在高负载情况下就会成为瓶颈点拖垮整个网站。

这时开发组面临一个选择,是继续在现有商城上优化,还是单独搞一套抢购系统?我们决定冒险一试,我和几个同事一起突击开发一套独立的抢购系统,希望能够绝境逢生。

摆在我们面前的是一道似乎无解的难题,它要达到的目标如下:

  • 只有一周时间,一周内完成设计、开发、测试、上线;
  • 失败的代价无法承受,系统必须顺畅运行;
  • 抢购结果必须可靠;
  • 面对海量用户的并发抢购,商品不能卖超;
  •  一个用户只能抢一台手机;
  • 用户体验尽量好些。

设计方案就是多个限制条件下求得的解。时间、可靠性、成本,这是我们面临的限制条件。要在那么短的时间内解决难题,必须选择最简单可靠的技术,必须是经过足够验证的技术,解决方案必须是最简单的。

在高并发情况下,影响系统性能的一个关键因素是:数据的一致性要求。在前面所列的目标中,有两项是关于数据一致性的:商品剩余数量