这周我们来学习一下小米的抢购系统开发实践。
小米公司在2011年8月16日首次发布了手机，立刻引起了市场轰动。随后，在一天多的时间内预约了30万台。之后的几个月，这30万台小米手机通过排号的方式依次发货，到当年年底全部发完。
然后便是开放购买。最初的开放购买直接在小米的商城系统上进行，但我们那时候完全低估了“抢购”的威力。瞬间爆发的平常几十倍流量迅速淹没了小米网商城服务器，数据库死锁、网页刷新超时，用户购买体验非常差。
市场需求不等人，一周后又要进行下一轮开放抢购。一场风暴就等在前方，而我们只有一周的时间了，整个开发部都承担着巨大的压力。
小米网可以采用的常规优化手段并不太多，增加带宽、服务器、寻找代码中的瓶颈点优化代码。但是，小米公司只是一家刚刚成立一年多的小公司，没有那么多的服务器和带宽。而且，如果代码中有瓶颈点，即使能增加一两倍的服务器和带宽，也一样会被瞬间爆发的几十倍负载所冲垮。而要优化商城的代码，时间上已没有可能。电商网站很复杂，说不定某个不起眼的次要功能，在高负载情况下就会成为瓶颈点拖垮整个网站。
摆在小米面前的是一道似乎无解的难题，它要达到的目标如下：
- 只有一周时间，一周内完成设计、开发、测试、上线；
- 失败的代价无法承受，系统必须顺畅运行；
- 抢购结果必须可靠；
- 面对海量用户的并发抢购，商品不能卖超；
- 一个用户只能抢一台手机；
- 用户体验尽量好些。
设计方案就是多个限制条件下求得的解。时间、可靠性、成本，这是我们面临的限制条件。要在那么短的时间内解决难题，必须选择最简单可靠的技术，必须是经过足够验证的技术，解决方案必须是最简单的。
在高并发情况下，影响系统性能的一个关键因素是：数据的一致性要求。在前面所列的目标中，有两项是关于数据一致性的：商品剩余数量、用户是否已经抢购成功。如果要保证严格的数据一致性，那么在集群中需要一个中心服务器来存储和操作这个值。这会造成性能的单点瓶颈。
在分布式系统设计中，有一个CAP原理。“一致性、可用性、分区容忍性”三个要素最多只能同时实现两点，不可能三者兼顾。小米要面对极端的爆发流量负载，分区容忍性和可用性会非常重要，因此决定牺牲数据的强一致性要求。
做出这个重要的决定后，剩下的设计决定就自然而然地产生了：
1. 技术上要选择最可靠的，因为团队用PHP的居多，所以系统使用PHP开发；
2. 抢资格过程要最简化，用户只需点一个抢购按钮，返回结果表示抢购成功或者已经售罄；
3. 对抢购请求的处理尽量简化，将I/O操作控制到最少，减少每个请求的时间；
4. 尽量去除性能单点，将压力分散，整体性能可以线性扩展；
5. 放弃数据强一致性要求，通过异步的方式处理数据。
本文参考文献：《程序员》杂志精选：“米粉节”背后的故事——小米网抢购系统开发实践