原文地址： https://mp.weixin.qq.com/s/ecU_CjTluQUX-420v3nWTQ
今天读了《小米网抢购系统开发实践》这篇文章，感受如下：
首先文章介绍了一个实际的案例，就是2014年的米粉节。2014年4月9日凌晨，我和同事们对小米网的抢购系统做了最后的检查与演练。几个小时后，小米网今年开年来最重要的一次大型活动“米粉节”就要开始了。这次米粉节活动，是小米电商的成人礼，是一次重要的考试。小米网从网站前端、后台系统、仓储物流、售后等各个环节，都将接受一次全面的压力测试。10点整，一波流量高峰即将到来，几百万用户将准点挤入小米网的服务器。而首先迎接压力冲击的，就是挡在最前面的抢购系统。而这个抢购系统是重新开发、刚刚上线不久的，这是它第一次接受这样严峻的考验。系统能不能顶住压力？能不能顺畅正确地执行业务逻辑？这些问题不到抢购高峰那一刻，谁都不能百分百确定。9点50分，流量已经爬升得很高了；10点整，抢购系统自动开启，购物车中已经顺利加入了抢购商品。一两分钟后，热门的抢购商品已经售罄自动停止抢购。抢购系统抗住了压力。我长舒一口气，之前积累的压力都消散了。我坐到角落的沙发里，默默回想抢购系统所经历的那些惊心动魄的故事。这可真是一场很少人有机会经历的探险呢。可以看出来作者的担心，以及这次人数的巨大，比较好的是服务器最后还是撑住了。
我们可以看一下抢购系统的原理图：
系统基本原理：在PHP服务器上，通过一个文件来表示商品是否售罄。如果文件存在即表示已经售罄。PHP程序接收用户抢购请求后，查看用户是否预约以及是否抢购过，然后检查售罄标志文件是否存在。对预约用户，如果未售罄并且用户未抢购成功过，即返回抢购成功的结果，并记录一条日志。日志通过异步的方式传输到中心控制节点，完成记数等操作。最后，抢购成功用户的列表异步导入商场系统，抢购成功的用户在接下来的几个小时内下单即可。这样，流量高峰完全被抢购系统挡住，商城系统不需要面对高流量。
对于抢购系统来说，最大的不同就是一天要经历多轮抢购冲击，而且有多种不同商品参与抢购。我们之前的抢购系统，是按照一周一次抢购来设计及优化的，根本无法支撑米粉节复杂的活动。而且经过一年多的修修补补，第一版抢购系统积累了很多的问题，正好趁此机会对它进行彻底重构。
第二版遇到了遇到了HTTP层Go程序内存消耗过多的问题。
我们的解决办法如下。在无法优化Go语言中GC机制时，要避免“雪崩效应”就要尽量避免服务占用的内存超过限制（50%），在处于这个限制内时，GC可以有效进行。可通过增加服务器的方式来分散内存压力，并尽力优化服务占用的内存大小。同时Go 1.3也对其GC做了一定优化。我们为抢购这个特定服务场景定制了新的HTTP包，将TCP连接读缓存大小改为1KB。在定制的HTTP包中，将缓存池的大小改为100万，避免读写缓存的频繁申请和销毁。当每个请求处理完成后，通过设置Response的Header中Connection为close来主动关闭连接。通过这样的改进，我们的HTTP前端服务器最大稳定连接数可以超过一百万。第二版抢购系统顺利完成了米粉节的考验。
总结：技术方案需要依托具体的问题而存在。脱离了应用场景，无论多么酷炫的技术都失去了价值。抢购系统面临的现实问题复杂多变。从这个时间可以看出，需求的增加就会迫使程序的变化，只有与时俱进才能蒸蒸日上，