小米网抢购系统开发实践阅读心得

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

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

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

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

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

HTTP服务层主要功能如下：

1. 进行基本的URL正确性校验；

2. 对恶意访问的用户进行过滤，拦截黄牛；

3. 提供用户验证码；

4. 将正常访问用户数据放入相应商品队列中；

5. 等待业务处理层返回的处理结果。

业务处理层主要功能如下：

1. 接收商品队列中的数据；

2. 对用户请求进行处理；

3. 将请求结果放入相应的返回队列中。

用户的抢购请求通过消息队列，依次进入业务处理层的Go进程里，然后顺序地处理请求，将抢购结果返回给前面的HTTP服务层。

商品剩余数量等信息，根据商品编号分别保存在业务层特定的服务器进程中。我们选择保证商品数据的一致性，放弃了数据的分区容忍性。

技术方案需要依托具体的问题而存在。脱离了应用场景，无论多么酷炫的技术都失去了价值。